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面向 数据 中 心 异 构 负 载 的 
低 成 本 协同 资源 供应 方法 和 系统 
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摘要 : 最 新 的 研究 分 析 表 明 ， 服 务 器 购置 费用 仍然 
t 应 问题 己 经 发 和 
有 好 地 应 对 这 种 异 构 怕 
个 协同 
峰 负 载 的 资源 消耗 ， 第 二 
作业 ， 我 们 构建 了 支持 


文中 ， 我 们 认为 
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资源 人 
， 基 于 四 
异 构 负载 


种 典型 的 异 


响 大 规模 数据 中 心 或 云 系统 
E 显 著 变 化 ， 异 构 负 和 载 已 经 成 为 大 规模 数据 中 心 的 常态 ， 而 目 
E。 本 文 报道 了 我 们 针对 这 
t 应 的 解决 方案 ， 通 过 充分 利用 异 构 负载 的 差异 ， 降 低 在 竞 
构 负载 : 并 行 批 处 理 


一 问题 


TE 


VEN 


销 的 主要 因素 。 在 本 


的 工作 。 我 们 的 贡献 


、Web 服务 、 搜 索引 


4 PhoenixCloud 系统 ， 能 够 有 效 地 进行 协同 资源 供应 ; 第 


+} 
m3 


| 真实 和 合成 的 负载 


三 ， 我 们 通过 使 
方案 与 现 有 的 非 


办 同 角 


坚决 方案 相 比 可 


心 或 云 系统 中 ， 包 
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[利用 统计 复 用 技术 


EC2 系统 或 实现 了 


初步 弹 怕 


日， 成 本 ， 异 构 负 载 


行 实 验 对 系统 进行 了 综合 的 评价 。 实 
DRAKA 
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验 结 


服务 器 购置 成 本 ， 该 方案 可 以 广泛 用 于 当 


果 显 示 ， 我 们 的 解决 
前 的 托管 数据 


mi 


资源 供应 技术 的 RightScale 系统 。 


1 引言 

当前 越 来 越 多 的 计算 和 存储 模式 正在 从 类 似 PC 的 客户 端 向 数据 中 心 双 或 (公共 ) eu 
系统 转移 ， 典 型 的 例子 有 EC2 服务 和 Google Apps。 转 向 服务 端 计算 的 驱动 力 不 仅 是 用 户 的 
需求 ， 如 管理 方便 〈 无 需 配置 或 备份 ) 和 使 用 方便 (支持 通过 浏览 器 B 的 访问 )， 还 有 大 规 
模 数 据 带 来 的 规模 经 济 效益 : 大 规模 规模 数据 中 心 芭 的 成 本 相对 于 小 规模 数据 中 心 可 以 节 


约 80 


96-9099"?! 
的 托管 数据 中 心 电 力 成 本 高 达 每 


9 然而 , 大 规模 数据 中 心 成 本 仍然 很 高 。 据 报 


My 


AB 


在 


月 五 百 六 十 万 美元 。 


提供 商 是 非常 


对 于 亚马逊 和 谷歌 等 数据 
于 传统 的 企业 系统 , 数据 
乎 无 关 紧 要 中 9。 第 二 ， 服 务 成 本 中 的 服务 器 硬 人 人 


HH 
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和 紧迫 的 问题 。 


P 心 的 成 本 模型 下 
P 心 的 人 力 成 本 因 


因此 如 何 


zs 32][44][46][51 
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降低 数据 中 心 的 成 本 对 于 资源 


获得 了 两 点 结论 : 第 一 ， 不 同 


成 本 贡献 


素 已 经 从 原来 在 总 成 本 
了 最 大 的 份额 G 


占 很 


高 上 


例 转 变 到 现在 几 
EHE — 25), 其 他 


成 本 还 包括 电源 及 冷却 基础 设施 的 成 本 、 电 力 成 本 及 其 他 基础 设施 的 成 本 , 这 些 成 本 很 大 程 
度 上 也 和 服务 器 数量 有 关 。 针 对 这 种 情况 ， 本 文 的 重点 是 如 何 降低 对 服务 器 的 需求 ,这 是 影 
响 数据 中 心 成 本 中 最 重要 的 因素 。 

目前 的 降低 服务 器 需求 的 解决 方案 可 以 分 为 两 类 : 第 一 ， 基于 虚拟 化 率 集 的 方式 ， 其 目 
的 是 :《〈1) . 解决 应 用 程序 隔离 或 噶 构 操 作 系统 所 造成 的 服务 器 扩张 问题 〈 即 由 于 未 充分 利 


用 应 月 


的 


服务 器 聚集 特性 , 造成 数据 中 心 占用 的 空间 和 消耗 的 服务 器 或 存储 资源 快速 增长 ); 


1 原文 发 表 于 IEEE Transaction on Computers, 标题 为 Cost-aware Cooperative Resource Provisioning for 


Heterogeneous Workloads in Data Centers 
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弹性 资源 。 


技术 意味 着 


EI RR 


商 必须 面 对 不 同类 


面向 数据 中 心 异 构 负载 的 低 成 本 协同 资源 供应 方法 和 系统 

(0 .在 托管 数据 中 心 ， 为 多 层 服务 9 四 或 科学 计算 负载 四 得 供 
的 系统 中 ， 利 用 统计 复 用 技术 7， 以 减少 对 服务 器 的 需求 。 复 有 
共享 资源 09, 
有 用 户 峰值 资源 需求 的 总 和 超过 数据 
源 e9， 以 最 大 限度 地 提高 销量 )， 从 而 将 多 个 轻 负 裁 的 应 
的 硬件 系统 上 

由 于 越 来 越 多 的 计算 移动 到 数据 中 心 ， 资 源 提供 
Web 服务 器 、 数 据 分 析 作业 、 并 行 批 处 


第 二 ， 在 EC2 


多 个 用 户 之 间 
cuc uu I 
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别 异 构 负载 (例如 
EVEN) 增加 引起 的 服务 器 扩张 的 挑战 。 这 种 现象 已 


经 受到 越 来 越 多 的 关注 。 例 如 ， 人 们 注意 到 在 Nutch Chttp://nutch.apache.org/) 搜索 引擎 系 


统 中 包括 两 个 主要 异 构 负 载 : 类 MapR 


educe 3 


VF 


月 30 日 北京 举行 的 IDC HPC 用 户 的 论 
里 作业 和 Web 服务 应 用 程序 合 
耗 特 点 和 性 能 目标 ， 我 们 将 在 第 3 章 讨论 
成 的 挑战 ， 己 不 能 简单 地 由 以 前 的 基 


Md 


并 到 一 个 数据 中 心 


于 虚拟 化 


xb. 波音 


Ly A 


行 数据 分 机 和 搜索 引擎 服务 ; 


Eo FHH 
。 由 于 异 构 负载 
的 聚合 扩展 来 解决。 


载 往 


论 这 一 问题 


而 ] 
张 的 挑战 


关于 电源 和 其 他 


DZ, H 
. X 


日, 只 利用 统计 复 用 或 超 售 资源 技术 也 不 能 
因素 ， 数 据 中 心 


j 效 地 应 对 卉 
的 规模 不 能 无 限 扩大 。 


在 2010 年 10 
司 也 报道 了 这 一 趋势 ,他们 将 并 行 批 处 
往 有 着 显著 不 同 的 资源 消 
的 增长 ， 服 务 器 扩张 所 造 


构 负 载 增加 造成 的 服务 器 扩 
在 大 量 用 户 和 服务 可 以 


随时 部 署 或 取消 部 署 的 环境 下 ， 类 似 EC2 一 样 利 用 统计 复 用 技术 使 得 系统 资源 利用 率 曲线 


保持 平滑 是 不 可 


能 。 此 外 , 超 售 机 制 对 于 资源 人 


应 是 一 个 概率 模型 ， 


因此 它 不 适合 关键 服务 。 
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可 知 ， 服 务 器 成 本 约 占 数据 


而 服务 器 成 本 是 由 系统 的 容量 决定 的 ， 
于 系统 容量 必 


而 降低 整个 数据 中 心 的 成 本 。 


必须 至 少 比 负载 的 资源 消耗 
我 们 可 以 通过 减少 资源 需求 的 尖峰 负载 ， 


并 且 


P 心 总 成 本 的 53.691, 
电力 与 基础 设施 成 本 也 和 系统 容量 密切 相关 。 


峰值 
以 节 


我 们 根据 资源 消耗 的 特点 和 性 能 
应 解决 方案 ， 


供 


以 降低 数据 中 心 负载 的 资源 消耗 峰值 
首先 , 我 们 利用 异 构 负 载 的 差异 ,提出 了 一 个 协同 的 资源 供 


大 ,所 以 资源 消耗 峰值 是 系统 容量 
省 服务 器 成 本 和 电力 以 及 基 而 


的 下 界 , 因 
设施 的 成 本 ,从 


此 ， 


br. 充分 利用 异 构 负载 的 差异 性 , 提出 了 协同 的 资源 


商 在 竞争 条 件 下 运行 异 构 的 负载 ,并 在 更 高 的 粒度 


技术 ， 以 节省 服务 器 成 本 。 
第 二 ， 我 们 基于 以 前 的 工作 Pol Pus. 


表 性 的 异 构 负 载 : 并 行 批 处 理 作 业 、Web 服务 器 、 搜 索引 擎 、MapReduce 作业 提供 协同 供 


应 资源 。 


第 二 章 


HEHA% 


。 我 们 的 贡献 包括 三 个 方面 : 


应 解决 方案 ,支持 服务 提供 
两 个 异 构 负载 的 组 合 


上 用 统计 复 用 


实现 了 一 个 创新 系统 一 一 PhoenixCloud， 为 四 种 有 代 


第 三 ， 我 们 对 PhoenixCloud 系统 和 类 EC2+RightScalelike 系统 进行 了 综合 评价 比较 。 


本 文 的 其 余部 分 安排 如 下 : 章 主要 描述 问题 的 重要 性 ; 第 三 章 主要 提出 了 协同 资源 
供应 的 解决 方案 ; 第 四 章 详细 描述 了 我 们 的 协同 资源 供应 解决 方案 第 五 章 对 系统 进行 了 全 
面 地 评估 和 比较 ;第 六 章 列 举 了 相关 工作 ;第 七 章 总 乡 
2 ”问题 定义 和 动机 

根据 文章 "9 的 观点 ， 服 务 器 的 购置 成 本 占 总 数据 中 心 总 成 本 很 大 部 分 。 从 成 本 分 
析 模 型 M9 来 看 ， 系 统 的 容量 大 小 是 降低 数据 中 心 成 本 的 关键 因素 : 一 方面 ,最 大 的 一 
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部 分 成 本 ， 即 服务 器 成 本 (53960 “是 由 服务 器 的 系统 容量 决定 的 ， 男 一 方面 ， 第 二 大 部 
分 的 数据 中 心 成 本 ， 即 电力 和 冷却 基础 设施 的 成 本 取决 于 最 大 设计 《额定 ) 功 耗 ， 这 个 值 是 


系统 容量 、 数 据 中 心 的 容错 度 和 功能 需求 所 共同 决定 的 。 


于 系统 容量 必须 至 少 大 于 负载 资源 消耗 的 峰值 
需求 ， 从 而 降低 服务 器 的 成 本 和 电源 及 冷却 基础 设施 的 成 本 。 由 于 每 个 事件 请 求 释放 或 供应 


因此 , 我们 必须 减少 尖峰 负载 的 资源 


~ 


二 
= 


资源 将 触发 所 设置 的 动作 ， 例 如 删除 操作 系统 或 数据 ， 在 类 EC2 系统 中 ， 弹 性 资源 供应 将 


导致 管理 上 的 开销 ， 管 理 开 销 可 以 由 下 面 的 公式 来 衡量 : 


管理 开销 = (累计 调整 资源 数量 )X 每 次 调整 的 平均 消耗 时 间 ) 
资源 提供 商 的 资源 消耗 总 量 是 有 效 资源 消耗 之 和 , 而 有 效 的 资源 消耗 是 负载 的 直接 消耗 


与 管理 开销 之 和 。 


我 们 对 尖峰 资源 消耗 和 有 效 的 资源 消耗 的 准 ® 


定义 如 下 : 


设 服务 提供 商 的 负载 是 w ios ;对 于 wo ,整体 ; 


去 行 持续 时 间 是 工 ,在 第 了 时 间 单位 (At) ， 


j=1,-,M ,资源 调配 给 w 的 服务 器 数量 是 C,， 则 尖峰 资源 消耗 为 (六 > C，,j =1,…M) 的 


最 大 值 ， 而 有 效 的 资源 消耗 是 Y CMS 


j=l 


当 用 户 租赁 资源 时 ， 费 用 按照 单位 时 间 的 粒度 


4t 收 取 。 例 如 ， 在 EC2 上 ， 租 赁 资 


源 的 单位 时 间 为 一 小 时 。 因 此 , 我 们 可 以 使 用 负载 的 有 效 资源 消耗 ， 即 租赁 资源 的 大 小 乘 以 
其 租赁 时 间 来 间接 地 反映 服务 提供 商 的 成 本 ,作为 标杆 指导 降低 成 本 的 工作 。 降 低 服务 器 购 


置 成 本 的 同时 不 能 牺牲 服务 提供 商 和 最 终 用 户 的 服务 质量 , 而 反映 质量 的 性 能 指标 和 不 同 的 


负载 密切 相关 : 对 于 并 行 批 处 理 作 业 或 MapReduce 作业 ， 主 要 关注 点 是 服务 提供 商 在 完成 


成 Bo 的 平均 时 间 。 对 于 Web 服务 器 和 搜索 引擎 


工作 时 的 吞吐 量 YH ， 而 最 终 用 户 关心 的 是 每 个 作业 的 平均 周转 时 间 ， 即 从 作业 提交 到 完 
， 服 务 提供 商 主 要 关注 的 是 以 每 秒 响应 的 


请 求 数 来 衡量 的 吞吐 量 5”， 而 最 终 用 户主 要 关注 每 个 请 求 的 平均 响应 时 间 ， 以 此 作为 服务 


质量 的 主要 指标 。 


在 此 背景 下 , 本 文 着 重 讨论 在 不 显著 影响 服务 提供 商 和 最 终 用 户 性 能 指标 的 情况 下 如 何 


降低 服务 器 成 本 。 如 上 所 述 , 以 节点 数量 表示 的 最 小 系统 容量 必须 要 至 少 大 于 负载 的 尖峰 资 
源 消耗 所 以 我 们 用 负载 尖峰 资源 需求 来 衡量 服务 器 最 低 成 本 。 我 们 的 资源 供应 解决 方案 专 
注 于 如 何 降低 尖峰 资源 需求 ， 同 时 又 不 会 严重 降低 服务 提供 商 和 最 终 用 户 的 性 能 指标 。 


为 什么 以 前 的 工作 未 能 提出 一 个 协同 解决 方案 ? 


首先 是 因为 用 户 通 常 为 并 行 批 处 理 作业 或 web 服务 “选择 专用 的 系统 ， 并 为 它们 对 应 


的 交互 式 /网 络 负载 和 批 处 理 负 载 安排 不 同 的 调度 机 制 ， 此外， 在 http://www.cs.huji.ac.il/ 
labs/parallel/workload/ 或 http://ita.ee.lbl.gov/html/ traces.html， 可 以 获取 公开 可 用 的 高 性 能 计 


标 。 


算 (HPC) 或 Web 服务 的 负载 数据 ， 因 此 大 多 研究 者 都 选择 把 如 何 优 化 同 构 负载 作为 研究 


其 次 ， 云 计算 是 近年 来 兴起 的 新 平台 。 在 亚马逊 的 EC2 成 为 公用 设施 之 后 ， 人 们 才 开 
和 认识 到 越 来 越 多 的 异 构 负载 会 出 现在 同一 个 平台 上 。 


第 三 ,在 同一 平台 上 聚集 异 构 负 载 的 日 志 数据 是 不 公开 的 ,因此 ,研究 人 员 没 有 公开 


Hu 


用 的 基准 测试 程序 和 负载 数据 (trace) 来 评价 他 们 的 解决 方案 ， 这 严重 阻碍 了 他 们 深入 研究 异 
构 负 载 的 协同 资源 供应 问题 。 为 克服 这 一 障碍 ， 我 们 发 布 了 云 计算 的 基准 测试 程序 集合 。 
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EC2 使 用 统计 复 用 技术 ,充分 地 不 


面向 数据 中 心 异 构 负 载 


| 


1 了 异 构 负载 差异 性 。 


的 低 成 本 协同 资源 供应 方法 和 系统 


我 们 的 工作 进一步 深入 , 在 更 


高 的 粒度 一 一 两 个 异 构 负载 的 组 合 层次 上 ， 充 分 利用 统计 复 


3 ”协同 资源 供应 模型 


随 着 越 来 越 多 的 计算 移动 到 数据 


的 资源 消耗 有 显著 不 同 的 特点 。 


用 特性 ， 以 节省 服务 器 成 本 。 


Pb, 资源 提供 商 对 于 越 来 越 多 的 异 构 负 载 需 要 有 相应 
的 资源 供应 手段 。 不 同 于 应 用 隔离 或 操作 系统 异 构 性 "(服务 器 聚集 ) 所 造成 的 服务 器 扩 
张 ,不断 增加 的 负载 类 型 和 不 断 增 长 的 负载 强度 对 系统 容量 规划 提出 了 新 的 挑战 ,因为 它们 


载 的 差异 性 ， 在 两 个 方面 节省 服务 器 的 成 本 。 


在 本 文中 ， 针 对 批 处 理 作业 、Web 服务 器 、 搜 索引 擎 、MapReduce 作业 ， 我 们 利用 负 


首先 ， 这 四 种 负载 在 时 间 、 强 度 、 规 模 、 持 续 时 间 和 资源 使 用 模式 方面 的 要 求 是 显著 不 


同 的 。Web 服务 器 的 负载 通常 由 一 系列 持续 时 间 短 (如 1 秒 之 内 的 ) 的 请 求 组 成 ， 尖 峰 负载 


与 平均 负载 的 比值 很 高 ， 通 过 资源 复 用 ， 


可 以 为 多 个 请 求 同 时 提供 服务 和 交错 提供 服务 ; 批 


处 理 作 业 的 负载 由 一 系列 资源 大 小 需求 有 所 不 同 的 作业 组 成 , 每 一 个 作业 是 并 行 或 串 行 的 应 


用 程序 ， 串 行 应 用 的 运行 时 间 更 长 ， 以 小 时 计算 ， 
虽然 MapReduce 作业 同 用 MPIT 编 写 的 批 处 到 


差异 : (一 ) MapReduce 作业 往往 是 1 


响 另 一 个 中。 这 种 任务 之 间 的 独立 性 和 MPI 批 处 


运行 并 行 应 用 程序 需要 一 组 独占 的 资源 ; 
EE 作业 有 很 多 相似 之 处 ,但 是 它们 有 两 个 显著 的 


各 种 不 同 大 小 的 数据 输入 组 成 ， 数 据 输入 决定 其 资源 
的 需求 规模 ; (二) 在 运行 时 ，MapReduce 的 任务 是 相互 独立 的 ， 所 以 杀 掉 一 个 任务 不 会 影 


里 作业 的 编程 模型 (MPI 任务 并 发 执行 并 


在 执行 过 程 中 存在 消息 交换 ) 形成 鲜明 的 对 比 。 


其 次 ,， 这 四 种 负载 的 性 能 指标 是 不 同 的 。 利 用 这 一 点 , 我 们 可 以 协调 运行 异 构 负载 的 服 
务 提供 商 的 资源 供应 行为 ， 以 减少 峰值 资源 消耗 。 在 一 般 情况 下 ,对 于 批 处 理 的 最 终 用 户 而 
言 ， 提 交 作 业 时 若 无 资 源 可 用 可 以 排队 等 待 。 然 而 ，Web 服务 ， 如 Web 服务 器 或 搜索 引擎 ， 
每 一 个 独立 请 求 需要 立即 响应 。 因 此 我 们 可 以 首先 满足 Web 服务 资源 请 求 ， 而 拖延 执行 并 


行 批 处 理 作 业 或 MapReduce 作业 。 


对 于 协同 资源 供应 , 我 们 提出 如 
下 两 项 指导 原则 : 


(1) 为 安全 或 隐私 的 考虑 ， 如 
果 服 务 提供 商 不 允许 协同 的 资源 供 
应 , 或 无 法 找到 一 个 协同 的 服务 提供 
商 , 资源 提供 商 将 为 其 负载 独立 供应 
资源 ; (2) 如 果 服 务 提 供 商 允许 ， 则 
资源 提供 商 以 包括 两 个 异 构 负载 的 
组 合 为 粒度 支持 协同 的 资源 供应 。 


对 于 每 组 异 构 负 载 , 我们 提出 了 
以 下 协同 的 资源 供应 模型 : 


系统 容量 -.… 


资源 上 界 -- 


资源 下 界 -- 


不 分 配给 优先 级 
较 低 的 服务 商 


分 配 到 一 个 服务 
商 或 其 协作 服务 
商 ， 如 果 其 处 在 
空闲 状态 则 分 配 


至 另 一 服务 商 


仅 分 配 到 一 个 服务 
商 或 其 协作 服务 商 


Kl. 系统 容量 和 两 个 资源 边界 


首先 , 当 服 务 提供 商 依赖 于 托管 数据 中 心 , 它 需 要 指定 两 个 资源 范围 : 资源 上 界 和 下 界 。 


资源 提供 商 保证 在 资源 下 界 中 的 资源 只 能 被 分 配 到 指定 的 服务 提供 商 或 其 协同 服务 提供 商 。 


”Message Passing Interface， 一 种 基于 消息 传递 的 并 行程 序 设计 标准 
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= 10 卷 第 


介 于 资源 


供 商 


供 商 。 


程 如 下 : 


5 期 


的 资源 请 求 , 但 
图 1 显示 了 


第 二 , 资源 提供 


信息 技术 快报 


Information Technology Letter 


是 


商 是 否 允 许 一 个 


资源 提供 商 设置 和 多 
选 人 加 入 组 合 的 考量 
的 资源 预订 阔 值 , 资源 提 
(候选 人 ) 的 资源 需求 上 限 总 和 不 超过 系统 容量 乘 以 资源 预订 阅 值 。 除 此 以 外 ， 两 个 服务 
供 商 候选 人 资源 下 界 的 总 和 必须 低 于 目前 系统 的 闲置 资源 的 大 小 。 
足 ， 这 两 个 服务 提供 商 候选 人 才能 加 入 组 合 。 


B=, 如果 一 个 组 合 被 允许 加 入 , 组 合 内 的 两 个 服 


因素 之 一 。 


pe 


E 护 的 资源 预订 闵 值 (RBT*) 作为 决定 


H, 
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上 界 和 下 界 的 之 间 资 源 , 资源 提供 商 首先 满足 指定 的 服务 提供 商 或 其 协同 的 服务 提 
两 个 边界 之 间 的 资源 处 于 闲置 状态 时 可 以 被 重新 分 配 到 另 一 个 服务 提 


系统 的 容量 和 两 个 资源 边界 之 间 的 关系 。 


两 个 服务 提供 商 组 成 的 候选 台 


昌 合 加 入 服务 对 象 决 策 过 


T 


Fe 


务 


源 提供 商都 会 为 其 分 配 数量 在 资源 下 界 以 内 的 资源 。 


第 


排队 的 负载 具 
理 作 业 ，Web 月 


PATHE 


0. 


i. 


ii. 


3. 


有 更 高 的 优先 级 。 例如， 


资源 


优先 


及 务 器 比 批 处 理 作业 


提供 商 设 置 


级 服务 提 


Va 


k 有 更 高 的 优先 级 , 因 
业 可 以 排队 ， 而 Web 服务 对 每 个 请 求 都 需要 立即 做 出 反应 。 
如 下 运行 时 算法 ( 详 见 附录 A 算法 D: 

个 使 用 率 参 考 值 CURRO. 和 一 个 比例 共享 
竞争 环境 下 协调 资源 共享 的 依据 。 我 们 定义 比例 
上 共 商 的 资源 下 界 (LB) 与 所 有 力 


VET BAT 1， 意 味 着 资源 被 超 售 。 
上 共 商 保证 所 有 加 入 系统 的 服务 提供 商 和 两 个 即将 力 


商 在 运行 
由， 对 于 每 组 两 个 异 构 负载 : 资源 请 求 需要 立即 做 出 反应 的 那个 负载 比 资源 请 求 可 
对 于 两 个 典型 的 异 质 性 负载 : Web 服务 器 和 并 行 批 
为 后 者 在 没有 资源 可 用 时 提交 的 作 


否 允 许 两 个 月 


及 务 提供 商 修 
通过 设置 合 


0 入 的 服务 提供 


只 有 当 两 个 条 件 同 时 


E 
JF 


构 的 负载 时 和 启动 时 


以 
处 


因子 (PSF )， 作 为 在 


NT 


享 因子 (PSF) 为 请 求 资 源 的 低 


0 入 的 较 低 的 优先 级 的 服务 提供 商 的 


资源 下 界 的 总 和 的 比值 。 使 用 率 为 所 有 服务 提供 商 分 配 的 资源 与 系统 的 容量 的 比值 


从 请 


求 队列 中 提取 


^if 


如 果 一 个 具有 较 高 优先 级 的 服务 提供 商 请 求 资源 , 资源 提供 商 将 按照 请 求 的 大 小 立 


即 分 


步 分 


Dd 
L^ 
e 


HH 
ZM 


配给 它 。 然 而 ， 如 
析 如 下 : 

对 于 一 个 较 低 优先 级 的 月 
源 超过 了 其 应 有 的 资源 .| 


A BUR TES 


及 务 提供 


E 级 的 服务 提供 商 请 求 资源 ， 则 需要 进 一 


商 , 如 果 其 所 被 分 配 资源 的 大 小 加 上 其 
上 限 ， 将 没有 资源 分 配给 它 ; 


否则 服务 提供 商 将 被 授予 一 部 分 所 要 求 的 资源 , 具体 如 何 分 配 | 


资源 提供 商 i 


过 用 使 用 率 参考 值 与 使 用 率 比较 来 次 定 。 计 算 方法 如 下 式 : 


AllocatedSize = MIN{ 所 要 求 资源 的 大 小 ， 未 分 配 资源 的 大 小 }XPSF。 


Hı 


当 使 
大 小 


] 率 不 比 


, 


, AllocatedSize: 分 配给 服务 商 的 资源 量 ; 


务 提 供 商 资源 的 大 小 按 下 式 计 算 : 
AllocatedSize = 〈 未 分 配 资源 的 大 小 ) XPSF. 


3 resource booking threshold 
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PSF: 


因子 


比例 共享 


使 用 率 参 考 值 大 的 时 候 , 如 果 所 请 求 的 资源 的 大 小 小 于 未 分 配 资源 的 
资源 提供 商 授 与 服务 提供 商 所 要 求 的 大 小 的 资源 , 否则 资源 提供 商 将 给 予 服 


4. 


al I d 


时 中 心 异 构 负载 的 1 


氏 成 本 协同 资源 供应 方法 和 系统 


查看 请 求 队列 是 否 还 有 未 处 到 


的 请 求 。 如 有 则 转 回 步骤 1, 


o 


否则 结束 


第 五 ， 服 务 提 供 商 根据 自己 的 资源 要 求 主动 决定 请 求 或 释放 资源 。 
最 后 ， 如果 服 务 提供 商 不 允许 协同 资源 供应 或 不 能 找到 一 个 协同 的 服务 提供 商 , 我 们 可 


以 将 协同 的 服务 提供 


当 我 们 假定 的 资源 提 作 
1。 这 种 情况 下 ， 表 明 对 于 


商 看 作 空 值 并 作为 一 个 独立 的 资源 供应 解决 方案 简化 上 述 模型 。 


t 商 有 无 限 的 资源 , CUE UE Be 
服务 提供 商 的 资源 请 求 该 提供 商 


直 和 使 用 率 参考 值 可 以 分 别 设置 为 
的 资源 是 足够 的 ， 所 以 资源 售 


是 


没有 必要 的 并 且 每 个 请 求 资源 远 小 于 系统 容量 。 


4  PhoenixCloud 的 设计 和 实现 


在 本 节 中 ， 在 我 们 以 前 的 系统 DawningCloud "? 后 基础 上 ， 我 们 给 出 了 PhoenixCloud 
系统 的 设计 和 实现 。 目 前 ，PhoenixCloud 支持 Web 服务 器 、 并 行 批 处 理 作 业 、 


搜索 引擎、 


MapReduce 作业 之 间 的 协同 资源 供应 。 它 可 以 扩展 使 用 于 其 他 数据 密集 型 的 编程 模型 ， 


例 


如 ， 类 Dryad 数据 流 和 All-Pairs (这 些 都 是 我 们 以 前 实现 的 Transformer 系统 所 支持 的 1 ) 。 


PhoenixCloud 存在 如 下 两 个 层次 架构 : 一 个 为 资源 提供 商 的 公 


Common Service Frame)， 男 一 个 为 服务 提供 商 的 瘦 运 行 环境 软件 (TRE，Thin Runtime 


服务 框架 (CSF, 


Environment)， 它 为 每 个 服务 提供 商 管理 资源 和 负载 。 两 个 层次 架构 意 谓 着 公共 服务 框架 和 


瘦 运 行 环境 是 分 离 的 : 


公共 服务 框架 


公 


资源 提供 商 供应 和 
服务 框架 的 支持 下 ,可 以 按照 需求 创建 一 个 瘦 运 行 环境 或 两 个 协调 的 瘦 运 行 环境 。 瘦 运 


管理 ,独立 于 任何 瘦 运 行 环境 。 在 
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行 


Hoc ROS T RU P 


图 2 


构 视 图 


ot 


ZH 


行 批 处 理 作业 或 


MapReduce 作业 的 瘦 运 行 环境 (PBI* TRE) 
和 一 个 Web 服务 器 的 瘦 运 行 环 境 (WS 


TRE) 复 用 了 公共 服务 框架 。 在 此 ， 我 们 只 
是 简单 地 给 出 了 公共 服务 框架 和 瘦 运 行 环 


境 的 主要 组 成 部 分 ， 
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由 组 件 的 细节 可 以 在 


我 们 公开 提供 的 技术 报告 号 中 找到 。 


在 公共 服务 框架 中 , 资源 供应 服务 负责 
协调 资源 供应 。 框 架 有 两 种 类 型 的 监视 器 : 


资源 监视 器 和 应 用 监视 器 。 在 每 个 节点 上 的 
资源 监视 器 监控 物理 资源 CPU 


NE LN 


交换 、 磁 盘 读 写 和 网 络 读 写 的 使 用 状况 ,应 
用 程序 监视 器 负责 检测 应 用 程序 的 状态 。 


管理 资源 , 与 公 


瘦 运 行 坏 境 有 三 个 组 成 部 分 : 
< 服务 框架 交互 。 调 度 器 负责 调度 作业 或 分 发 请 求 。Web 门户 是 一 个 


对 应 的 运行 时 环境 具体 功能 集合 由 


公共 服务 框架 实现 ， 


而 瘦 运 行 环境 只 为 负载 实现 共同 的 核心 功能 。 


述 了 PhoenixCloud 系统 的 体系 
， 其 中 一 个 3 


”监控 及 S 


L 其 他 服务 A 


WS: web 服 务 器 
PBJ: 并 行 批 处 理 作业 


D 
M 


开行 批 处 理 作 业 瘦 运行 环境 及 web 服 务 
瘦 运 行 环境 与 公共 服务 框架 的 交互 


管理 者 、 调 度 器 、Web 门户 。 管 理 者 负责 处 理 用 户 的 请 求 ， 


户 界面 ， 最 终 
图 2 显示 了 两 个 瘦 运 行 


^ Parallel Batch Job， 并 行 批 处 理 作业 
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图 形 用 


] 户 通过 它 提交 和 监视 作业 或 应 用 程序 。 


环境 和 公共 服务 框架 之 间 的 交互 。 两 个 服务 提供 商 运 行 异 构 负载 
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的 协调 和 资源 提供 商 的 情况 如 下 : 


资源 供应 服务 商 制 订 的 资源 供应 政策 决定 什么 时 间 将 多 少 资源 提供 给 瘦 运 行 环境 , 如 何 
协调 两 个 协同 的 运行 时 环境 之 间 的 资源 。 第 三 章 中 ， 我 们 介绍 了 资源 供应 政策 。 


管理 嚣 即 每 个 瘦 运 行 环境 的 管理 实体 , 其 上 的 资源 管理 策略 决定 了 管理 器 请 求 或 释放 资 
源 的 时 机 和 数量 ， 按 照 什么 样 的 政策 提供 资源 供应 服务 。 


对 于 不 同 的 负载 ， 调 度 策 略 有 不 同 的 含义 。 对 于 并 行 批 处 理 作 业 或 MapReduce 作业 ， 
调度 策略 决定 调度 器 何 时 以 及 如 何 选择 工作 (或 任务 ) 运行 。 对 于 Web 服务 器 ， 调 度 策 略 
包括 两 个 具体 的 政策 :实例 调整 政策 和 请 求 分 配 政策 。 实 例 调整 政策 决定 Web 服务 器 的 实 
例 被 调整 的 时 机 和 程度 ， 请 求 分 配 政策 决定 根据 什么 标准 如 何 分 发 请 求 。 


以 一 个 web 服务 瘦 运 行 环境 和 一 个 并 行 作业 瘦 运 行 环境 分 别 与 公共 服务 框架 交互 为 例 ， 
过 程 如 下 : 


(1). web 服务 管理 器 从 资源 供应 服务 获得 资源 下 限 内 的 初始 资源 , 并 以 相 匹 配 的 规模 运 
行 Web 服务 器 实例 。 


(2). web 服务 管理 器 和 负载 均衡 器 (一 种 负责 为 Web 服务 器 实例 分 配 负载 的 调度 器 ) 

交互 ， 以 设置 其 请 求 分 配 策略 。web 服务 管理 器 向 负载 平衡 器 注册 网 络 服 务 器 实例 
的 IP 和 端口 信息 ， 负 载 平衡 器 根据 请 求 分 配 政策 分 发 请 求 到 Web 服务 器 实例 。 我 
们 整合 Linux 虚拟 服务 (LVS) (http://www.linuxvirtualserver.org/) 作为 IP 层 的 负载 
平衡 器 。 


(3) 在 每 个 节点 上 的 监视 器 定期 检查 资源 的 利用 率 并 报告 给 web 服务 管理 器 。 如 果 性 
能 值 超过 闵 值 ， 例 如 ， 平 均 实例 消耗 的 CPU 使 用 率 超过 80% web 服务 管理 器 会 
根据 实例 调整 政策 调整 Web 服务 器 实例 的 数量 。 


(4). 根据 当前 的 Web 服务 器 实例 ，web 服务 管理 器 向 资源 供应 服务 请 求 或 释放 资源 。 
对 于 并 行 批 处 理 作业 或 MapReduce 作业 ，PhoenixCloud 采用 资源 管理 政策 如 下 : 


租赁 的 资源 单位 时 间 用 L 表示 。 我 们 假定 资源 的 租 期 是 租赁 资源 的 单位 时 间 的 正 整 数 
倍 。 在 类 EC2 系统 中 ， 对 于 并 行 批 处 理 作 业 ， 每 个 最 终 用 户 负 责 手 工 管理 资源 。 我 们 假定 
如 果 一 个 作业 运行 结束 , 用 户 具 在 每 个 租赁 资源 单位 时 间 的 末尾 释放 资源 。 这 是 因为 : 第 一 ， 
类 EC2 系统 以 租赁 资源 的 时 间 单 位 〈 一 小 时 ) 收取 资源 使 用 费用 ， 第 二 ， 最 终 用 户 很 难 预 
测 作业 完成 时 间 ， 因 此 即时 释放 资源 给 资源 提供 商 几乎 是 不 可 能 的 。 

我 们 定义 “资源 调整 比例 ”为 ， 在 队列 中 的 所 有 作业 所 积累 的 资源 需求 与 瘦 运 行 环境 所 
有 的 现 有 资源 之 比 。 当 资源 调整 比例 大 于 1 时 , 说 明 对 于 需要 立即 运行 的 作业 而 言 ， 必 须 
有 比 目 前 瘦 运 行 环境 已 有 的 资源 更 多 的 资源 才能 满足 其 运行 需求 。 

我 们 设置 了 两 个 调整 资源 的 阐 值 ， 分 别 为 “请 求 资源 的 比例 闵 值 ”( 用 UU 表示 〉 和“ 释 
放 资源 的 比例 阔 值 ”( 用 V 表示 )。 请 求 和 释放 资源 的 过 程 如 下 : 

(1). 并 行 批 处 理 作 业 管 理 器 注册 一 个 周期 性 定时 器 《租赁 资源 的 时 间 单 位 )， 触 发 每 个 
单位 时 间 的 资源 调整 。 在 定时 器 的 推动 ,并行 批 处 理 作业 管理 器 周期 性 地 扫描 队 
列 中 的 作业 。 

(2)， 如 果 调 整 资源 比例 超过 了 请 求 资源 比例 的 闵 值 , 并 行 批 处 理 作 业 管 理 器 会 请 求 大 小 
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e 
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IDES 


为 DR1 的 资源 ，DR1 计算 方法 如 下 : 


对 并 行 批 处 理 作 业 : 
的 所 有 作业 需要 资源 的 总 和 ) -《 当 前 并 行 批 处 开 


DR1 = (队列 


拥有 的 资源 )) /2) 


对 MapReduce 作业 : 


DR1 = 目前 队列 ， 


最 大 的 作业 所 需 的 资源 


居中 心 异 构 负 载 的 低 成 本 协同 资源 供应 方法 和 系统 


作业 瘦 运 行 环境 


(3). 对 并 行 批 处 理 作业 ， 如 果 资 源 调 整 比例 不 超过 正在 请 求 资源 比例 的 阔 值 , 但 目前 在 
队列 中 最 大 作业 的 资源 需求 的 比例 比 瘦 运 行 环境 所 拥有 的 资源 的 比例 大 ， FRAT AE 
处 理 作业 管理 器 将 按照 DR2 的 大 小 请 求 资源 ，DR2 计算 方法 如 下 : 
DR2- (目前 队列 中 最 大 的 作业 所 需要 的 资源 ) - (目前 由 瘦 运 行 环境 拥有 的 闲置 资 
源 ) 
对 于 并 行 批 处 理 作业 , 当 目 前 在 队列 中 最 大 作业 的 资源 需求 比例 比 瘦 运 行 环境 所 拥 


明显 不 同 于 
情况 。 


(如果 资源 调整 比例 比 释放 资源 比例 阔 值 低 ， 


有 的 资源 比例 大 时 , 这 意味 着 最 大 的 作业 | 
行 批 处 理 作业 ，MapReduce 的 任务 是 相互 独立 的 所， 所 以 不 会 发 4 


并 行 批 处 理 作 业 管 至 


(ReleaSing Size). 的 大 小 释放 闲置 资源 。 其 计算 方法 为 : 


RSS = (并 行 批 处 型 
(5)， 如 果 资 源 供应 服务 3 


郑 等 全 认为 ， 在 管理 
更 简单 ， 更 准确 。 我 们 也 持 同 样 的 看 法 。 在 本 文 ， 


作业 瘦 运 行 环境 所 拥 
动 提供 资源 给 并 行 批 处 理 作 业 管 理 


有 的 闲置 资源 ) /2。 


数据 中 心 Web 服务 时 ,实际 的 实验 比 许多 管理 外 
， 我 们 通过 部 署 的 实际 系统 来 决定 两 台 


Web 服务 器 和 一 个 搜索 引擎 负载 跟踪 的 资源 管理 政策 。 


5 ”性 能 评价 
5.1 真实 负载 日 志 


器 ， 后 者 将 获得 资源 。 
务 模型 更 便宜 ， 


于 没有 可 利用 的 资源 , 将 无 法 运行 。 请 注意 ， 
FE 这 种 


器 将 按照 RSS 


对 于 并 行 批 处 理 作业 ,我 们 从 http://www.cs.huji.ac.il/labs/parallel/workload/ 选 择 三 个 典型 


负载 日 志 : 
是 为 期 两 个 星期 也 


年 04 


一 个 为 期 两 个 星期 的 真实 的 日 志 片 段 ， 从 2007 年 2 月 1 


真实 的 
对 应 的 集群 系统 配置 为 128 个 节点 。 


的 集群 系统 配置 是 1002 节点 (不 包括 管理 节点 等 )。 


对 于 Web 服务 器 ， 我 们 使 
RHE: 一 个 是 世界 杯 期 间 〈 记 为 WorldCup) 的 负载 
月 20 日 外 ， 另 外 一 个 是 从 繁忙 
至 9 月 10 


从 1995 年 8 月 28 


;大平 洋 夏令 时 (适用 于 美 区 


Fa Fa TIN 


。 同 时 ， 我 们 选择 公 玫 


、 华 盛 顿 州 、 俄 勒 冈 州 等 ) 
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志 ， 时 间 为 从 1998 4 


美国 宇航 局 (NASA) 的 记 SC，SDSC BLUE 和 LLNL Thunder。 美 国 宇航 局 iPSC 
志 片 段 ， 从 1993 年 10 月 01 日 0 时 00 分 03 秒 (PDT?) J 
SDSC BIUE 是 为 期 两 个 星期 的 真实 日 
月 25 日 15 点 00 分 03 秒 (PDT 开始 ， 对 应 的 群集 配置 为 144 节点 。LLNL Thunder 是 
月 18 时 10 分 25 秒 ( 段 ) 玫 


于 始 ， 
志 片 段 ， 从 2000 


F 始 ， 对 应 


从 http://ita.ee.lbl.gov/html/traces.html 获得 的 两 个 真实 的 负 


E6 月 7 日 至 6 


的 互联 网 服务 供应 商 ClarkNet 获得 的 HTTP 负载 
F 可 用 的 匿名 搜索 引擎 的 负载 


志 ， 时 间 


m 


AW 10 卷 第 5 


时 间 在 2011 年 从 3 月 28 日 零点 00 分 00 秒 到 23:59:59", 我 们 在 本 文 的 其 余 


信息 技术 快报 


Information Technology Letter 


索 负 载 (SEARCH). 


5.2 合成 负载 日 志 


据 我 们 所 知 , 在 同一 平台 
志 无 法 公开 获得 。 


作业 负载 


们 创建 了 合成 的 负载 日 志 。 
较 低 的 优先 级 ， 


Web 月 
尖峰 资源 消耗 


上 共存 的 并 行 


例如 ， 


, 


因此 ， 在 我 们 的 实验 中 ， 根 据 5.1 frt 
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部 分 称 之 为 搜 


批 处 理 作 业 、Web 服务 器 、 搜 索引 擎 、MapReduce 
3 的 实际 负载 日 志 ， 我 


我 们 使 用 二 元 组 (PRC。, PRC, ) "代表 两 个 异 构 负载 日 
并 行 批 处 理 作业 或 MapReduce 作业 ,而 BB 具有 更 高 的 优先 级 例如， 
Fy air IR GME, PRC, 是 A 中 一 个 最 大 的 作业 的 最 大 的 资源 需求 ，PRCs Æ B 的 
例如 ， 二 元 组 (100,60)， 是 在 SDSC BLUE 和 World Cup 的 跟踪 日 志 的 基础 


上 得 来 的 ， 有 两 方面 的 含义 : A). 我 们 按照 不 同 的 缩放 常量 
和 World Cup 负载 ; (2) .在 相同 的 仿真 集群 系统 , 在 SDSC BLUE ! 


需求 和 World Cup 的 尖峰 资源 消耗 分 别 是 100 和 60 个 节点 。 


5.3 实验 方法 


为 评价 和 比较 PhoenixCloud 和 类 似 EC2+ RightScale 的 系统 ， 我 们 采取 以 下 实验 方法 。 


5.3.1 实际 系统 上 部 署 的 实验 


对 于 Web 


负载 ， 我 们 获得 资源 消耗 


服务 器 和 搜索 引擎 负载 , 通过 在 真实 系统 上 部 署 和 运行 5.1 GE 
志 。 对 于 MapReduce 作业 ， 我 们 也 通过 在 物理 硬件 上 部 署 和 运 


行 实际 系统 进行 实验 ， 硬 件 配置 如 5.5.2 节 所 示 。 


5.3.2 为 异 构 负载 设计 的 模拟 实验 


一 个 典型 
素 对 实验 结果 


的 负载 日 志 的 周期 往往 是 几 周 , 甚至 儿 个 


的 影响 ,我们 需要 经 常 执行 


ES 


志 : A 


因子 分 别 缩 放 了 SDSC BLUE 


最 大 的 作 


TASES TH) AY 


F 价 系统 中 许多 关键 因 
耗 时 的 实验 。 然 而 ， 当 我 们 进行 几 百 种 负载 日 志 实 


业 的 最 大 资源 


到 的 三 个 实际 


验 时 ,它们 的 资源 消耗 多 达 上 万 个 节点 , 采用 真实 系统 实验 的 方法 明显 是 不 值得 的 。 所 以 我 


们 使 用 模拟 方法 加 速 实验 进程 
得 在 三 个 小 时 左右 


po TRUE EC 


Obs oP 


用 元 


了 真实 系统 来 验证 我 们 模拟 系统 的 精度 。 


5.4 测试 床 


如 


位 的 2.6.18-xe 
配置 为 1 GB 


(1.6GHz) 的 处 理 器 ， 操 作 系统 是 64 位 的 
2.6.5-7.97-SMP 版 本 内 核 Linux。 每 个 gdnode 类 
节点 配置 为 4GB 的 内 存 和 一 个 


1.60GHz 处 型 
2.6.18-194.8.1. 


图 3 所 示 , 测试 平台 包括 三 种 类 型 的 节点 ， 
名 称 分 别 以 glnode, ganode, gdnode 开头 ， 每 个 
glnode 节点 配置 为 2GB 内 存 和 两 个 
至 强 的 〈2.00GHz) 处 理 器 ， 操 作 系统 是 一 个 64 


四 核 英 特 尔 


n 内 核 的 Linux。 每 个 ganode 节点 
的 内 存 和 2 个 AMD Optero242 


四 核 英 特 尔 至 强 
器 ， 操 作 系 统 是 一 个 64 位 的 
el5 版 本 内 核 的 Linux。 所 有 节点 都 


€ PRC, Peak Resources Consumption， 峰 值 资源 消耗 
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上 快 提 交 和 完成 的 作业 的 
两 个 星期 的 日 志 重 放 。 此 外 ， 在 第 5.7 节 ， 我 1 


图 3. 


因子 


测试 床 


为 100。 这 种 加 速 使 
门 在 物理 


E 


TE 件 


使 用 1Gb/s 的 交换 机 连接 。 
5.5 实际 系统 上 部 署 的 实验 
5.5.1 运行 真实 网 络 服务 器 和 搜索 引擎 系统 


消耗 跟踪 


CentOS 操作 系统 。 我 们 部 署 了 真实 的 PhoenixCloud 系统 : 负载 平衡 器 是 直接 路 | 
(HTTP: // kb.linuxvirtualserver. 


m 


于 每 个 Xen 虚拟 机 ， 


个 监视 器 ， 


于 负载 很 轻 ， 


TRES 


f CB. 我 们 部 署 真实 的 系统 ， 以 者 


DE 


因此 


中心 异 构 负 载 的 低 成 本 协同 资源 供应 方法 和 系统 


取 两 个 Web 服务 器 和 一 个 搜索 引擎 负载 的 资源 


我 们 在 glnode 类 的 每 个 节点 上 部 署 了 8 个 Xen 虚拟 机 Chttp://www.xensource.com/). X} 


核心 处 理 器 和 256 MB 内 存 ， 使 用 64 位 的 2.6.18XEN 内 核 版 本 


org/wiki/ LVS/ DR); 每 个 虚拟 机 上 分 别 部 署 了 


LVS 和 其 他 服务 都 部 署 在 ganode004 节点 上 。 


模式 的 LVS 


一 个 代理 和 一 


我 们 选择 最 少 连接 调度 策略 (http://kb.linuxvirtualserver.org/wiki/Least-Connection 


Scheduling〉 来 分 发 请 
为 负载 发 生 器 , 开源 应 月 
LVS 和 ZAP! 的 版 本 分 别 是 0.9.0，1.24 和 1.4.5. 
ganode003 上 。 


Web 日 志 是 由 WorldCup 负载 中 使 用 2.22 缩放 
过 实验 获得 决定 实例 调整 政策 所 需 的 数据 ; 第 二 步 , 获得 资源 消耗 日 


用 了 实例 调整 政策 。 在 这 个 配置 下 ，web 服 
调整 Web 服务 实例 的 数量 。 在 16 个 虚拟 实验 的 测试 床上 部 署 了 16 个 ZAP! 
我 们 记录 了 实际 


的 吞吐 量 


在 第 一 步 
S s 
即 每 个 虚拟 机 上 部 署 


ER. y 


rz 


向 


请 求 的 平均 响 
应 时 间 大 幅 


应 时 间 小 于 50 上 毫秒。 
增加 至 1528 毫秒 。 


， 我 们 部 署 的 PhoenixCloud 禁 


平均 响应 时 间 和 CPU 核心 的 平均 使 用 
一 台 虚 拟 机 上 ， 对 于 虚拟 机 来 说 ，VCPU 的 数量 就 是 CPU 的 核 数 。 
平均 使 用 率 就 是 VCPU 的 平均 利 


一 个 实例 。 


求 ， 选 择 httperf Chttp://www.hpl.hp.com/research/I] Linux/httperf/) fF 
日 程序 ZAP ! Chttp://www.indexdata.dk/) 作为 目标 Web 服务 器 。httperf 


两 个 httperf 实例 部 署 在 ganode002 和 


因子 得 至 


当 m MC a 


1。 实 验 包括 两 个 步 


cs 


JD 0 


因为 我 们 保证 一 个 CPU 核心 被 分 配 到 
因此 ， 每 个 CPU 核心 的 


<< 


始 服 务实 例 有 7 


超过 8096, web 服务 管理 


基于 上 述 观 察 形成 了 我 们 的 实例 调整 政策 ， 我 们 选择 月 
整 ZAP! 实例 数 ， 并 设置 80% 作 为 闷 值 。 对 于 ZAP!, 
大 个 。 如 果 在 过 去 的 20 秒 , 所 有 的 Web 服务 实例 所 消耗 VCPU 的 平均 利 月 
前 所 有 的 Web 服务 实例 所 消耗 VCPU 


器 将 增加 一 个 实例 。 


RATE 


如 果 当 


] 率 。 我 们 观察 到 ， 当 VCPU 的 平均 使 用 率 低 于 80% 时 ， 
然而 ， 当 VCPU 的 平均 利用 率 增 加 为 97% ， 请 求 的 平均 


H VCPU 的 平均 利用 率 为 准绳 来 
1 订 的 实例 调整 政策 如 下 : 初 


PES 


的 平均 利用 率 小 于 过 去 的 20 POH (0.80 x((n—1)/ n) F n 为 当前 实例 的 数量 )，web 服 


务 管 


调整 
和 虚 
Jn. du 


PUBLICS 


— SEARCHIf 


在 上 述 策略 


理 器 将 减少 一 个 实例 。 


在 第 二 步 ， 我 们 部 署 PhoenixCloud 时 启用 了 实例 调整 政策 。web 
政策 调整 Web 服务 实例 的 数量 。 在 实验 中 ， 我 们 仍然 记录 实 
量 之 间 的 关系 。 我 们 观察 到 ， TM 700 
量 呈 线性 增加 。 这 表明 ， 实 例 


, 我们 获得 了 WorldCup 负载 跟踪 
我 们 分 别 使 用 772.03 和 171.29 为 缩放 因子 获得 两 个 星 


IH: gt. 


际 否 
EWH, 


J 能 并 


调整 政策 是 合适 的 ， 


TON 


个 星期 资源 消耗 日 志 


JD o 


= 
N 


的 资源 消耗 跟踪 


J^ o 


5.5.2 在 硬件 上 执行 MapReduce 作业 的 实验 
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服务 管理 器 根据 实例 
平均 响应 时 间 
当 虚 拟 机 数量 增 
不 是 最 优 的 。 

用 同样 的 方法 ， 
期 ClarkNet 负载 和 一 个 匿名 搜索 引擎 
资源 消耗 的 追踪 日 志 ， 可 以 在 附录 B.1 中 查看 。 
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本 节 通 过 在 真实 系统 上 部 署 MapReduce 作业 负载 评价 了 PhoenixCloud 系统 。 


测试 平台 由 20 个 X86-64 节点 组 成 ， 即 图 3 中 ， 编 号 从 gdnode36 到 gdnode55 的 节点 。 
我 们 选择 了 一 系列 广泛 使 用 的 MapReduce 作业 作为 我 们 的 MapReduce 负载 ， 其 中 的 细节 ， 
可 以 在 附录 B.S 中 查看 。 同 时 ， 我 们 重 放 在 5.5.1 小 节 介绍 的 SEARCH 资源 消耗 跟踪 日 志 。 
我 们 使 用 (PRC。, PRC, ) 表示 MapReduce 作业 和 搜索 引擎 的 负载 的 尖峰 资源 消耗 。 在 这 个 实 
ern (PRC,, PRC,) 是 (19,64) 。 


实验 中 使 用 0.21.0 版 本 的 表 1. MapReduce 作 业 和 搜索 引擎 
Hadoop 运行 MapReduce 作业 ， 负载 一 SREACH 的 资源 提供 南 度 量 
Hadoop Hj JDK 版 本 是 系统 资源 消耗 | 节约 的 峰 | 节约 的 资 
1.6.0.20。 我们 在 一 个 节点 上 配 (节点 数 x 小 时 )| 值 消耗 | 源 消耗 
tt Namenode 〈 名 字 节 点 ) 和 PhoenixCloud 960 63.2196 57.33% 
jobtracker (作业 跟踪 器 )， 而 在 非 协作 2250 0 0 


男 外 一 个 节点 上 配置 Datanode 数据 节点 ) 和 TaskTracker《〈 任 务 跟踪 器 ) 。 在 Hadoop 
中 ， 块 大 小 为 64MB， 在 每 个 节点 上 共有 4 个 映射 计算 槽 和 2 个 规约 计算 槽 ， 并 且 调度 策略 为 
先 来 先 服务 CFCFSD 。 


表 2. MapReduce 作 业 的 服务 提供 商 指 标 
完成 | 平均 周转 资源 消耗 
作业 数 | 时 间 秒 ) | (节点 数 x 小 时 ) 


我 们 采取 在 第 4 章 介 绍 的 资源 管 
理 政策 。 在 PhoenixCloud 系统 中 ， 对 系统 
于 MapReduce fE MV, Je 2 X 
是 [R0.28/E19/U5/V0.05/L60]"。 我 们 分 
别 设置 资源 预订 闵 值 (RBT〉 和 使 用 
率 参 考 值 CURR) 的 值 为 1。 在 Hadoop 中 ， 一 个 MapReduce 作业 的 资源 需求 由 它 的 map 
任务 的 数量 来 决定 ， 因 此 请 求 资源 数 为 map 任务 数 除 以 每 个 节点 的 map 计算 槽 数 。 为 防止 
MapReduce 作业 尖峰 资源 需求 超过 测试 平台 的 系统 容量 ， 我 们 使 用 缩放 比例 来 缩放 每 个 资 
源 请 求 〈 即 资源 请 求 除 以 缩放 比例 )。 对 于 目前 的 20 节点 测试 平台 ， 缩 放 比 例 为 16。 对 于 
类 EC2 系统 ， 我 们 根据 其 时 间 惟 一 个 接 一 个 运行 MapReduce 作业 。 最 后 ， 我 们 累加 所 有 
MapReduce 作业 的 资源 消耗 获得 其 峰值 和 资源 消耗 总 量 。 出 于 同样 的 原因 ， 我 们 还 是 使 用 
缩放 因子 ， 以 减少 MapReduce 作业 的 尖峰 资源 需求 。 


从 上 面 的 结果 可 以 看 到 ， 我 们 的 算法 很 好 地 适用 于 MapReduce 作业 。 相 比 非 协同 的 类 
EC2+RightScale 系统 , PhoenixCloud 可 以 分 别 降 低 63.21% 的 尖峰 资源 消耗 和 57.33% 资 源 消 
耗 总 量 。 与 此 同时 ，PhoenixCloud 系统 的 否 吐 量 和 类 EC2 系统 相同 ， 在 PhoenixCloud 和 类 
EC2 系统 中 ， 每 个 作业 的 平均 周转 时 间 分 别 为 5658，310 秒 ， 平 均 每 个 作业 延迟 258 秒 。 


5.6 模拟 实验 


在 本 节 中 , 我 们 对 类 EC2+RightScale 和 PhoenixCloud 系统 使 用 Web 服务 器 和 并 行 批 处 
理 作业 负载 的 追踪 进行 了 性 能 比较 。 实 验 设 置 如 下 : 


5.6.1 模拟 系统 


(1). 模拟 集群 上 文 提 到 的 负载 跟踪 是 从 不 同 配置 的 平台 获得 的 。 例 如 ， 美 国 宇 航 局 
iPSC 是 从 由 单 处 理 器 节点 组 成 的 集群 系统 上 获得 的 ; SDSC BLUE 是 从 由 8 个 处 理 


PhoenixCloud | 477 568 960 
非 协作 477 310 2250 


yj 


7 First Come First Served 
8 B 代表 协同 资源 的 大 小 (节点 数 );U RAR URNS EIB, V 代表 释放 资源 的 比例 闵 值 ，G 代表 释 
放 资 源 弹性 系数 ; L 代表 租赁 时 间 单 位 。 
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器 节点 组 成 的 集群 系统 获得 的 ; LLNL Thunder 是 从 由 处 理 器 节点 组 成 的 集群 系统 
上 获得 的 。 在 其 余 的 实验 中 ， 我 们 的 模拟 集群 系统 以 美国 宇航 局 IPSC 的 集群 为 蓝 
本 ， 只 由 单 处 理 器 节点 组 成 。 


(2). 模拟 类 EC2+RightScale 系统 基于 PhoenixCloud 框架 , 我 们 实现 和 部 署 了 类 EC2+ 
RightScale 系统 的 测试 平台 ， 如 图 4 所 示 。 模 拟 系统 包括 两 个 模拟 模块 : 工作 模拟 
器 和 资源 模拟 器 。 相 比 真 实 的 PhoenixCloud 系统 ， 我 们 只 保持 资源 供应 服务 ，web 
服务 管理 器 和 并 行 批 处 理 作 业 管 理 器 。 作 业 模 拟 器 读 取 节 点 上 的 跟踪 日 志文 件 并 发 
送 资 源 请 求 给 资源 供应 服务 , 资源 供应 服务 为 每 个 作业 分 配 相 应 的 资源 。 当 每 个 作 
业 运 行 完 成 ,作业 模拟 器 将 释放 资源 给 资源 供应 服务 。 资 源 模 拟 器 模拟 资源 消耗 的 
变化 并 驱动 web 服务 管理 器 请 求 或 释放 资源 给 资源 供应 服务 .因为 RightScale 对 于 
Web 服务 负载 提供 与 PhoenixCloud 系统 相同 的 可 伸缩 管理 , 我们 只 是 使 用 了 第 5.5.1 
节 提 到 的 相同 的 Web 服务 资源 消耗 妃 踊 日 志 。 


(3). 模拟 PhoenixCloud 我 们 模拟 了 
2 中 所 示 的 真实 PhoenixCloud 
系统 。 其 中 保持 了 资源 供应 服务 、 
并 行 批 处 理 作业 管理 器 、web 服务 
管理 和 调度 器 , 其 他 的 服务 被 删除 
T o 资源 供应 服务 执行 第 3 章 定义 
的 协同 的 资源 供应 模型 。 


作业 仿真 器 


I 


PBJ 管 理 


资源 提供 服务 


图 4， 类 EC2+RightScale 模 拟 系统 


5.6.2 实验 配置 


(D. 并 行 批 处 理 作 业 调 度 策 略 对 并 行 批 处 理 作 业 ，PhoenixCloud 采取 首次 适应 
Cfirst-fit) 调度 策略 。 首 次 适应 调度 策略 以 作业 到 达 的 顺序 扫描 队列 中 所 有 的 作业 ， 
系统 会 选择 能 够 满足 其 资源 需求 的 第 一 个 作业 去 执行 。 类 EC2 系统 不 需要 调度 策 
略 ， 因 为 并 行 批 处 理 作 业 运 行 时 ， 每 个 最 终 用 户 负 责 手动 请 求 或 释放 资源 。 


(2). 资源 管理 政策 对 于 并 行 批 处 理 作 业 ， 我 们 采用 了 第 四 章 描 述 的 资源 管理 政策 。 
5.6.3 系统 极限 容量 下 的 实验 


在 附录 B.2 中 ， 我 们 假定 资源 提供 商 有 无 限 的 资源 ， 并 展示 了 实验 结果 。 在 本 节 中 ,我 
们 假设 的 资源 提供 商 有 不 同 的 系统 容量 的 有 限 资源 ， 然 后 我 们 报告 了 实验 的 结果 。 

5.1 节 中 介绍 的 六 个 负载 日 志 有 三 种 组 合 。 我 们 使 用 如 下 异 构 负载 组 合 : (APSC, 
WorldCup),，(SDSC，Clark)，(LLNL，SEARCH))， 它 们 的 资源 数量 分 别 是 : ((128, 128) 
(144, 128), (1002, 896)). 


通过 大 量 的 实验 比较 ， 我 们 设置 PhoenixCloud 系统 的 基线 参数 : (PSC, WorldCup) 和 
(SDSC, Clark) 为 [R0.5/E400/U1.2/V0.1/L60]，(LLNL,SEARCH) 为 [R0.5/E3000/U1.2/V0.1/ 
L60]. [Ri/Ej/UK/VVLm] 表 示 : R 代表 两 个 资源 下 限 的 总 和 与 PRC, 和 PRC 的 总 和 的 比值 ， 
值 为 i。E 表示 两 个 资源 的 上 限 边界 的 总 和 ， 值 为 j; U 代表 请 求 资源 比例 阔 值 ， 值 为 k; 资 
源 释 放 阔 值 比例 用 V 表示，] 为 值 .， 租 赁 资源 的 时 间 单 位 用 工 表示，m〔 分 钟 ) 为 值 。 在 附 
录 B.4 节 ， 我 们 探讨 了 PhoenixCloud 系统 中 不 同 参数 的 影响 。 
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每 个 实验 进行 6 次 , 我 们 的 报告 取 6 次 实验 的 平均 值 。 在 表 3 中 ,对 于 不 同 的 系统 的 容 


量 ， 即 4000、5000、6000， 除 了 服务 提供 商 的 基线 参数 ， 我 
MERE RBT 分 别 设 置 为 0.5 12. SFE (上 面 提 到 的 两 个 资源 上 界 的 总 和 )，E[A/B/C] 


门将 使 用 率 参考 值 URR 和 资源 


别 表 示 : 对 于 CPSC, WorldCup) 负载 组 合 ,两 个 上 限 的 总 和 是 A; 对 于 CSDSC, Clark) 


分 
负载 组 合 ， 两 个 上 限 的 总 和 为 B; XF (LNL, SEARCH) 负载 组 合 ， 两 上 界 


从 表 4、 表 5、 表 6、 表 7 和 表 


8， 我 们 可 以 看 出 ， 对 于 不 同系 统 的 77 
容量 配置 ,我 们 的 算法 性 能 特别 好 : 


从 资源 提供 商 角 度 看 ，Phoenix 
Cloud 可 以 节省 相当 数量 的 尖峰 资 
源 消耗 。 当 PhoenixCloud 的 系统 
量 下 降 到 4000 个 节点 时 ,仅仅 是 是 


的 总 和 是 C. 
表 3. 不 同系 统 容量 的 详细 配置 

系统 容量 
系统 E[A/B/C] URR RBT* 
(节点 数 ) UBI 
4000  PhoenixCloud [400/400/3000] 0.5 
5000 PhoenixCloud [400/400/3000] 0.5 
6000 PhoenixCloud [400/400/3000] 0.5 


AX 


类 EC2+RightScale 容许 的 最 小 系统 


源 将 会 立即 满足 不 同 ， 


两 方面 原因 


: (1) .与 在 类 EC2 系统 中 
并 行 批 处 理 作 业 可 在 PhoenixCloud 系统 中 
用 PhoenixCloud 系统 可 以 降低 峰值 资源 消耗 和 资源 消耗 总 量 ; (2) 


排队 ， 因 


在 竞争 条 件 下 设置 使 用 率 参 考 值 URR 和 比例 共享 因子 PSF 可 以 有 
从 服务 提供 商 角度 看 ， 以 完成 了 


TT t 使 用 率 参考 值 ，Usage rate reference 
”资源 预定 阅 值 ，Resource booking threshold 


类 

容量 的 65.3%, PhoenixCloud 可 以 分 别 比 类 EC2+RightScale 系统 节省 尖峰 资源 消耗 和 资源 
消耗 总 量 20% 和 43%。 这 有 每 个 批 处 理 作业 所 需 的 资 
此 资源 供应 商 使 
.在 PhoenixCloud 系统 中 ， 
效 地 降低 尖峰 资源 消耗 。 


[ 作 的 数量 计 ，PhoenixCloud 吞吐 量 与 类 EC2+RightScale 


系统 变化 不 大 (最 大 跌幅 仅 为 0.2%); 平均 周转 时 间 有 少量 的 增加 (对 NASA 的 iPSC、SDSC 


和 LLNL， 最 大 延迟 时 间 


EC2+RightScale 系统 节省 35%、13% 和 21%。 究 其 原 


PhoenixCloud 排队 ， 而 在 类 EC2 系统 中 每 个 批 处 理 作业 所 需 的 资源 将 会 立即 满足 ， 
业 完 成 的 数量 和 平均 周转 时 间 反 而 会 受到 影响 PhoenixCloud 的 资源 管理 


Mud 


IT 


很 小 ， 但 是 服务 提供 商 的 资源 消耗 却 能 显著 节省 。 


表 4. PhoenixCloud 系 统 不 同系 统 容量 下 6 个 真实 负载 对 应 的 资源 提供 商 指 标 
峰值 资源 消耗 有 效 资源 消耗 


增加 分 别 为 为 34%、34% 和 2196) 而 相应 的 资源 消耗 量 分 别 比 类 


因 如 下 : 并 行 批 处 理 作业 可 以 在 


资源 消耗 总 量 


因此 作 


LE 策略 对 性 能 的 影响 


ZUR (节点 数 ) (节点 数 x 小 时 ) (节点 数 x 小 时 ) 
六 个 负载 “ 非 协 作 6126 677190 687441 
4000 . PhoenixCloud 3518 545450 551845 
5000 . PhoenixCloud 3283 546395 552846 
6000 ^ PhoenixCloud 2899 543569 549832 
K5. NASA ipPSC 负 载 在 系统 不 同 容量 下 的 服务 提供 商 指标 
系统 容量 峰值 资源 消耗 平均 周转 时 间 资源 消耗 
(节点 数 ) (BD) (节点 数 x 小 时 ) 
六 个 负载 “ 非 协作 2603 573 54118 
4000 PhoenixCloud 2603 766 35786 
5000 PhoenixCloud 2603 738 35621 
6000 . PhoenixCloud 2603 733 35146 
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表 6. SDSC Blue 负载 在 不 同系 统 容量 下 的 服务 提供 商 指标 
平均 周转 时 间 资源 消耗 


系统 容量 系统 完成 作业 数 


Gib) (节点 数 x 小 时 ) 
六 个 负载 “ 非 协作 2657 1975 35838 
4000 “PhoenixCloud 2656 2642 31231 
5000 PhoenixCloud 2652 2546 31654 
6000 PhoenixCloud 2654 2535 31573 


表 7. LLNL Thunder 负 载 在 不 同系 统 容量 下 的 服务 提供 商 指标 
平均 周转 时 间 ”资源 消耗 


ben ec x 

系统 容量 系统 完成 作业 数 D) (节点 数 x 小 时 ) 

六 个 负载 非 协 作 7273 2465 339416 
4000 ”PhoenixCloud 7261 2941 270847 
5000 “PhoenixCloud 7262 2882 271233 
6000 PhoenixCloud 7262 2978 268298 


#8. PhoenixCloud 系 统 在 不 同系 统 容量 下 所 节省 的 资 
源 使 用 峰值 和 资源 消耗 总 量 

m 节约 的 峰值 ”节约 的 资源 

系统 容量 。 系统 PONE Miet 

资源 消耗 消耗 总 量 


iul 


4000 PhoenixCloud 42.57% 19.72% 
5000 PhoenixCloud 46.41% 19.58% 
6000 PhoenixCloud 52.68% 20.02% 


5.6.4 不 同 数量 合成 异 构 负 载 的 实验 
本 节 我 们 评估 PhoenixCloud 在 从 6 到 120 个 不 同 的 合成 异 构 负 载 组 合 下 的 效率 。 


合成 的 负载 是 基于 5.1 节 中 的 介绍 生成 的 ， 分别 是 CIPSC,WorldCup), (SDSC, Clark), 
(LLNL，SEARCH)。 当 我 们 执行 一 组 (6N + 6) 个 负载 的 跟踪 实验 ， 我 们 产生 N 个 新 的 负 
载 组 合 如 下 : 


我 们 记录 第 i 个 负载 组 合 为 : 


((iPSC, ,WorldCup, ),(SDSC, Clark, )(LLNL, SEARCH, ,)i=1,.…,N)。 


JE (PSC, WorldCup),(SDSC Clark), (LLNL,SEARCH )) 每 个 负载 日 志 分 成 CN +1) 部 分 。 
在 相同 负载 日 志 组 合 中 ,为 防止 在 同一 时 期 创建 重复 的 跟踪 负载 ,对 于 iPSC, SDSC 或 LLNL， 
我 们 交换 前 i 部 分 和 其 余部 分 ， 获 得 


((iPSC, ),(SDSC, ),(LLNL, )) ; 
对 于 Clark, WorldCup 或 SEARCH， 我 们 交换 后 i 部 分 和 其 余部 分 获得 
((WorldCup, ),(Clark, ),(SEARCH, )) 。 
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对 并 行 批 处 理 作 业 负 载 的 跟踪 ， 我 们 采取 IPSCi 作为 一 个 例子 : 首先 ， 我 们 定义 
Sub = ((336 x 3600 x i/(N +1) 第 二 ， 对 于 已 经 提交 的 作业 ， 如 果 其 时 间 戳 上 比 Sub 小 ， 我 们 
重 置 其 提交 时 间 为 Ct (336x3600 -Sub)), FUJA t-Sub. 


对 于 Web 服务 负载 的 跟踪 ， 我 们 以 Clark 作为 一 个 例子 。 我 们 定义 


MP = ((336xi)(N+1)) 。RC,,j=1,…,336 是 Clark 负载 跟踪 的 第 j 个 小 时 的 资源 消耗 。 对 于 
合成 负载 Clark;,i=1,…,N ， 如 果 j<MP，RC;; -RCys, 4,4» fill, RC; - RC; -MP。 


于 使 用 了 大 量 的 负载 跟踪 ,我 们 假定 资源 提供 商 有 无 限 的 资源 ,并 分 别 设置 资源 预定 
阅 值 和 参考 使 用 率 为 1 (解释 见 第 三 章 )。 我 们 在 PhoenixCloud 系统 中 设置 基线 参 
数 : [RO.5/E100000/U1.2/V0.1/L60]. E100000 意味 着 每 个 服务 提供 商 有 更 大 的 资源 上 限 ， 并 
会 得 到 足够 多 的 资源 。 表 9 总 结 了 类 EC2+RightScale 系统 和 PhoenixCloud 系统 运行 不 同 数 
量 的 负载 在 资源 提供 商 维度 上 的 指标 比较 。 


从 表 9 中 ， 我 们 可 以 观察 到 更 大 KI. 运行 不 同 数目 负载 时 ,PhoenixCloud 系 统 所 节 


规模 的 部 署 ， 我 们 的 解决 方案 可 以 节 省 的 峰值 资源 和 资源 消耗 总 量 

省 更 多 的 服务 器 成 本 。 对 于 小 规模 峰值 资源 消耗 ”| 节约 的 峰值 | 节约 的 资源 
(6126 节点 )、 中 等 规模 (28206 节 (类 EC2-RS 55) | 资源 消耗 | 消耗 总 量 
点 )、 大 规模 部 署 (116030 节点 )， 我 6126 18.01% | 17.22% 

们 的 解决 方案 分 别 比 类 EC2+Right- 28206 57.60% 15.32% 
Scale 方案 节省 服务 器 成 本 18.01%、 56920 61.14% 16.52% 


57.60% 和 65.54%。 116030 65.54% 16.56% 


请 注意 ， 表 9 中 ， 对 于 六 个 负载 。 “RightScale 

的 跟踪 ，PhoenixCloud 系统 的 配置 与 表 8 略 有 不 同 ， 因 此 有 不 同 的 结果 。 首 先 ， 在 表 9 中 ， 
我 们 假定 每 个 服务 提供 商 有 一 个 较 大 的 资源 上 限 ; 第 二 ， 表 9 ds 我 们 假定 资源 提供 商 拥有 
无 限 的 资源 ， 将 资源 预定 阔 值 和 参考 使 用 率 分 别 设置 为 1 。 


5.7 模拟 系统 的 准确 性 


为 了 验证 我 们 模拟 系统 的 精度 ， 我 们 在 测试 平台 上 部 署 了 真正 PhoenixCloud 系 统 。 测 试 
平台 由 40 个 X86-64 节 点 组 成 ， 如 图 3 所 示 ， 编 号 从 gdnode36 到 gdnode75。 


真实 的 web 服 务 负载 已 经 在 5.5.1 节 运行 过 了 ， 因 此 此 处 我 们 在 物理 硬件 上 运行 并 行 批 处 
理 负 载 。 我 们 合成 了 一 个 并 行 批 处 理 作业 的 负载 日 志 ， 其 中 包括 大 小 从 8 到 64 个 CPU 不 等 的 
100 个 作业 。100 个 作业 需要 在 10 小 时 内 提交 到 PhoenixCloud 系 统 ， 平 均 提 交 作 业 的 时 间 间 隔 
为 300 秒 。 我 们 的 实验 包括 两 个 步 又: 首先 ， 我 们 把 合成 的 并 行 批 处 理 负载 提交 到 真实 的 
PhoenixCloud 系 统 上 ， 然 后 收集 负载 日 志 。 第 二 ， 我 们 根据 通过 实际 系统 的 实验 获得 的 负载 
志 ， 在 模拟 系统 上 再 次 提交 了 相同 的 负载 ,然后 比较 真实 和 模拟 系统 的 指标 ， 以 评估 模拟 
系统 的 准确 性 。PhoenixCloud 系 统 的 基线 参数 是 [R0.5/E40/U1.2/V0.1/L60]， 我 们 分 别 设置 
资源 预订 闵 值 RBT 和 使 用 率 参 考 值 URR 为 1 。 通 过 实验 ， 我 们 发 现 ， 真 实 PhoenixCloud 系 统 
的 尖峰 资源 消耗 和 资源 消耗 总 量 的 比值 和 模拟 系统 的 都 分 别 约 为 1.14， 由 此 验证 ， 我 们 的 模 
拟 系统 是 足够 准确 的 。 


6 相关 工作 


国内 外 相关 工作 可 以 从 以 下 四 个 角度 总 结 : 
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6.1 节省 数据 中 心 成 本 的 方法 和 系统 


基于 虚拟 化 的 聚集 方面 ， 沃 格 尔 斯 (Vogel) 等 5 总 结 了 过 去 的 和 最 新 的 工作 ， 提 出 了 
基于 虚拟 化 的 聚集 方案 ， 以 应 对 应 用 程序 隔离 或 操作 系统 异 构 所 造成 服务 器 扩张 。 在 托管 数 
据 中 心中 ,很 多 人 利用 虚拟 机 器 为 多 层次 的 服务 或 高 性 能 计算 已 提供 弹性 资源 供应 汪 。 切 
Ei (Chase) 等 人 吕 提 出 在 托管 数据 中 心 为 为 共存 的 服务 供应 资源 ， 自 动 适应 负载 ， 从 而 提 


统计 复 用 方面 ， 萨 哈 里 亚 〈Zaharia) 等 2 指出 ， 过 去 的 EC2 系 统 利用 统计 复 用 技术 来 
降低 服务 器 的 购置 成 本 。 乌 尔 噶 昂 卡 〈Urgaonkar) 等 人 9 提出 的 超 售 资源 的 方法 ， 最 大 限 
度 地 为 更 多 的 大 量 轻 负载 应 用 程序 提供 资源 ,使 得 这 些 应 用 程序 可 以 在 一 个 给 定 的 系统 配置 
上 运行 , 但 是 他 们 只 使 用 大 量 固定 强度 的 轻 负载 服务 来 验证 结果 。 经 过 对 多 个 单一 的 或 合并 
的 应 用 程序 做 详细 的 分 析 ， 崔 〈 音 译 ， Cho) 等 多 为 预测 聚集 的 应 用 的 平均 功 耗 和 维持 功 
耗 开 发 了 相应 的 模型 。 


6.2 数据 中 心软 件 基 础 设施 


OpenNebula Chttp://www.opennebula.org/) 和 Haizea (http://haizea.cs.uchicago.edu/) 这 两 
个 相辅相成 的 开源 项 目 可 以 用 来 管理 虚拟 私有 /混合 云 的 基础 设施 lI。 斯 坦 纳 (Steinder) 等 
人 器 的 研究 表明 ， 虚 拟 机 器 使 得 异 构 负载 可 以 构建 在 任何 服务 器 上 。 我 们 以 前 研制 的 
DawningCloud R PO 0 旨 在 为 解决 科研 社区 如 何 从 云 计算 的 规模 经 济 中 受益 的 问题 。 辛 德 
*$ (Hindman) AFE T Mesos 一 个 多 种 集群 的 计算 框架 , 包括 : Hadoop 和 MPI 
等 。 在 [5][18][25][20][26] 中 提 到 的 数据 中 心软 件 基 础 设施 系统 都 属于 同一 领域 的 研究 工作 ， 
但 是 这 些 均 不 支持 异 构 负载 的 协同 资源 供应 。 


6.3 资源 供应 和 调度 


斯 坦 纳 等 上 5 针对 同 构 负 载 系统 ， 开 发 了 一 系列 新 的 自动 化 机 制 ， 从 而 可 以 更 有 效 地 调度 
非 交 互 式 作 业 负 载 。 西 尔 韦 斯 特 (Silberstein) 等 9 为 具有 不 同 资源 需求 的 大 规模 并 行 任务 设计 
了 一 个 相应 的 调度 算法 。 


bok Gare, Lin) 等 [9 提供 了 一 个 系统 级 调度 机 制 ，VSched。VSched 可 以 保证 交互 
式 负 载 的 执行 率 和 交互 性 能 ， 并 在 一 台 服 务 器 上 为 虚拟 机 提供 软 实时 保证 。 马 戈 (Margo? 
等 (3 研究 TeraGrid 系 统 的 元 调度 能 力 ( 网 格 应 用 的 联合 调度 )， 包 括 分 布 式 集群 格 点 之 间 的 
用 户 资 源 预 留 设置 。 索 托 马 约 尔 (Sotomayor) 等 0 提出 了 租赁 管理 架构 的 设计 ， 但 只 考虑 
了 同 构 负载 ， 即 混合 最 佳 适 应 租赁 请 求 和 提前 预订 请 求 的 并 行 批 处 理 作 业 。 


KPEE (Isard) 等 2 和 萨 哈 里 亚 等 2 的 研究 重点 在 于 解决 直接 连接 存储 的 低 端 系统 上 类 
MapReduce 数 据 密集 型 作业 的 调度 公平 性 和 数据 局 部 性 之 间 的 冲突 。 在 异 构 的 主 从 平台 上 ， 
DURE (Benoit) 等 的 关注 于 处 理 独立 和 相同 任务 的 集合 组 成 的 多 应 用 的 调度 问题 。 萨 德 哈 
F ILI (Sadhasivam) 等 6 提出 以 更 细 粒 度 执行 队列 中 的 作业 ， 以 增强 Hadoop 中 调度 的 公 
平 性 。 

在 非 协同 资源 供应 和 调度 方面 ， 瓦 尔 斯 普尔 热 (Waldspurger) 等 8" 实现 了 彩票 调度 一 一 
一 个 新 的 随机 资源 分 配 机 制 ， 它 对 计算 相对 的 执行 率 提 供 了 有 效 的 应 答 式 的 控制 。 金 伟 〈 译 
d Jin) 等 6 提出 了 一 种 以 中 间 人 请 求 调 度 的 方式 实现 比例 共享 资源 控制 的 方法 ， 来 共享 
服务 。 


6.4 数据 中 心 和 云 基准 测试 程序 


"i 
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基准 评估 程序 是 评价 计算 机 系统 的 基础 。 和 久 剑 锋 等 人 史 系 统 地 确定 了 数据 中 心 三 类 以 知 
吐 量 为 导向 的 负载 ， 其 目标 是 增加 以 处 理 的 用 户 请 求 、 数 据 、 支 持 的 最 大 并 发 用 户 数 来 计量 


的 吞吐 量 


四 


(Volume of throughput); 同时 为 描述 负载 和 为 负载 而 设计 的 数据 中 心 系统 定义 了 


个 


> 


新 术语 -高 通 量 计算 (High Volume Throughput Computing, HVC). #2875 (Luo) 等 名] 
是 出 一 个 新 的 测试 基准 程序 集 ，CloudRank-D， 用 来 总 
算 系 统 。 贾 (Jia〉 等 9 选取 了 不 同 领域 的 三 十 一 个 代表 性 应 用 作为 大 数据 应 用 测试 程序 基 
准 集 一 BigDataBench 。 


S 


测 和 比较 运行 大 数据 应 用 程序 的 云 计 


7 ”结束 语 


在 本 文中 ， 我 们 通过 充分 利用 异 构 负 载 的 差异 性 ， 提 出 了 协同 资源 供应 解决 方案 ， 以 节 
省 服务 器 购置 成 本 。 为 此 ， 我 们 构建 了 一 个 创新 性 的 系统 ， 称 为 PhoenixCloud 系 统 。 此 系统 


让 


能 够 为 以 下 四 种 有 代表 性 的 异 构 负载 提供 协同 供应 资源 ， 并 行 批 处 理 作 业 、Web 服 务 器 、 搜 
索引 擎 、MapReduce 作 业 。 我 们 提出 一 个 新 的 实验 方法 ， 将 真实 和 模拟 系统 的 实验 相 结合 ， 


并 对 我 们 的 系统 进行 了 综合 评价 。 我 们 的 实验 显示 ， 对 于 非 协同 的 类 EC2+RightScale 系 统 ， 
通过 在 更 大 的 粒度 (两 种 异 构 负 载 的 组 合 ) 上 利用 统计 复 用 的 优势 ， 我 们 的 算法 获得 了 很 大 
收益 ; 对 于 小 规模 (6126 节 点 ) 、 中 等 规模 〈28206 节 点 ) 、 大 规模 部 署 〈116030 节 点 )， 


我 们 的 解决 方案 比 非 协 同 资源 供应 系统 分 别 节 和 省 服务 器 成 本 18%、58%、66%。 
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附录 A 系统 资源 供应 的 运行 时 算法 


受理 位 于 队列 最 前 的 
服务 提供 商 资 源 申 请 


源 分 配给 
服务 提供 商 


申请 资源 的 服务 将 资 


提供 商 优 先 级 


申请 资 源 总 总 合 加 已 分 


RR El NUS 不 分 配 资源 


式 (1) 计 算 
分 配 资源 


按 公 
结果 4 


将 资源 分 配给 
服务 提供 商 


申请 的 资源 
NER AR AES 


按 公式 (2) 计 算 
结果 分 配 资源 


分 配 资 源 =Min{ 所 要 求 资源 的 大 小 ， 未 分 配 资源 的 大 小 }xPSF C 


分 配 资源 = 未 分 配 资源 的 大 小 xPSF (2) 
图 中 : 

LB: 资 源 下 界 UB: 资 源 上 界 PSF: 比 例 共享 因子 
URR :使 用 率 参 昭 


附录 B 性 能 评价 


B. 1 三 个 资源 消耗 日 志 


图 1、 图 2 和 图 3 GER World Cup. ClarkNet, SEARCH 负载 资源 消耗 数据 。 所 有 
三 个 资源 消耗 的 日 志 中 平均 资源 需求 和 尖峰 资源 需求 〈 峰 值 的 资源 的 需求 是 64 个 虚拟 机 
的 比率 都 很 高 。 其 中 SEARCH 日 志 由 重复 一 个 匿名 24 DIE a CK 14 倍 构造 成 的 ， 以 
保持 它 和 World Cup 和 ClarkNet 的 日 志 等 长 。 
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a 
So 


AR 
[e] 


以 虚拟 机 数量 表示 的 资源 


1 16 31 46 61 76 91 106 121136 151 166 181 196 211226 241 256 271 286 301 316 331 


时 间 (小 时 ) 


IRBE. ”世界杯 两 周期 间 的 资源 跟踪 日 志 


以 虚拟 机 数量 表示 的 资源 消耗 


- 
e 


源 消 耗 


xx 
D 
o 


以 虚拟 机 数量 表示 的 


m 
[e] 


附录 B 图 3， SEARCH 负载 日 志 


附录 B 表 1. ”6 个 真实 负载 对 应 不 同 资源 提供 商 的 系统 指标 
峰值 资源 消耗 有 效 资源 消耗 资源 消耗 总 量 


(节点 数 ) (节点 数 x 小 时 ) (节点 数 x 小 时 ) 
6 个 负载 非 协作 6126 677190 687441 
6 个 负载 ”PhoenixCloud 5019 563975 571157 
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附录 B 表 2. ”负载 NASA iPSC 对 应 不 同 服务 提供 商 的 系统 指标 
负载 系统 完成 作业 数 “平均 周转 时 间 CORPO 资源 消耗 (节点 数 x 小 时 ) 
6 个 负载 非 协作 2603 573 54118 
6 个 负载 ”PhoenixCloud 2603 741 36258 
附录 B 表 3.， ”负载 SDSC BLUE 对 应 不 同 服务 提供 商 的 系统 指标 
负载 系统 完成 作业 数 “平均 周转 时 间 ( 秒 ) ”资源 消耗 (节点 数 x 小 时 ) 
6 个 负载 非 协作 2657 1975 35838 
6 个 负载 ”PhoenixCloud 2654 2607 32091 


附录 B 表 4. — LLNL Thunder 负 载 对 应 不 同 服务 提供 商 的 系统 指标 
负载 系统 完成 作业 数 ”平均 周转 时 间 ( 秒 〉 资源 消耗 (节点 数 x 小 时 ) 
6 个 负载 非 协作 7273 2465 339416 
6 个 负载 ”PhoenixCloud 7272 2844 288323 


B.2 无 限 资源 条 件 下 的 基本 模拟 实验 


我 们 使 用 在 5.1 节 介 绍 的 主 文件 执行 了 负载 的 追踪 实验 。 在 这 个 实验 中 ， 我 们 假定 资源 
提供 商 所 拥有 的 资源 足以 满足 所 有 的 服务 提供 商 , 这 意味 着 由 服务 提供 商 发 出 的 每 个 资源 请 


求 相对 


于 资源 供应 商 所 拥有 的 资源 总 量 是 非常 小 的 。5.1 节 介 绍 的 主 文件 中 


的 六 个 负载 追踪 


共 形 成 三 种 组 合 。 我 们 用 Comb 1 代表 (IPSC，WorldCup)，Comb_2 代表 (SDSC, Clark), 


Comb 3 代表 (LLNL，SEARCH)。 对 于 Comb 1, (PRC4 PRCg) 是 (128, 128) ; 对 于 


Comb 2, (PRC,, PRCg) 是 (144 , 128) ;对 于 Comb 3, (PRC,, PRCg) 是 (1002, 896). 


附录 B.3 | 


， 我 们 探讨 了 


H CPRCaA，PRCs) 表示 的 不 同 规模 对 性 能 指标 芯 


影响 。 我 们 设置 


PhoenixCloud 中 的 基线 参数 如 下 : [R0.5 / E100000 / U1.2 / V0.1 / L60]. 
所 有 的 服务 提供 商 有 更 高 的 资源 上 限 。! 
i Bü RBT 和 使 用 率 参 考 值 URR 为 1。( 人 参见 第 三 章 主要 文件 ， 


E100000 意味 着 ， 


] 分 别 设置 资源 预 


于 资源 提供 商 有 无 限 的 资源 ， 我 人 
解释 )。 


每 个 实验 进行 6 次 ， 我 们 的 报告 取 6 次 实验 的 平均 值 。 表 1、 表 2、 表 3 和 表 4 总结 了 


关于 资源 提供 商 和 服务 提供 者 的 实验 结果 。 在 类 EC2+RightScale 系统 


» 资源 提供 商 为 Web 


服务 和 并 行 批 处 理 作 业 负 载 独立 供应 资源 。 同 时 ， 在 PhoenixCloud 系统 中 ，Web 服务 负载 
比 并 行 批 处 理 作业 有 更 高 的 优先 级 ， 因 此 Web 服务 的 资源 请 求 将 被 立即 满足 。 所 以 ， 在 这 


NI 


t 商 和 最 终 用 


两 个 系统 中 对 于 两 个 Web 服务 负载 的 追踪 有 着 相同 或 相近 的 性 能 指标 。 因 
户 ， 我 们 只 观测 了 3 


对 于 资源 提供 商 , 资源 消耗 总 量 是 有 效 资源 消耗 和 管理 开销 的 总 和 。 我 们 在 测试 平台 上 


PERE ARS, FE LEAS 


部 署 了 真实 的 PhoenixCloud 系统 ， 分 配 和 回 
印 载 以 前 的 运行 时 环境 包 ， 安 装 和 局 


十 算 管 


a a Jf 4 : 


此 ， 对 于 服务 提 


行 批 处 理 作 业 负 载 的 性 能 指标 。 


T 


收 一 个 节点 的 平均 开销 是 225 秒 ， 步 又 包括 部 
动 新 的 运行 时 环境 包 。 我 们 根据 下 


管理 开销 =( 累 计 的 调整 资源 的 计数 ) Xx 〈 平 均 安装 时 间 ) 
从 表 1、 表 2、 表 3 和 表 4 中， 我 们 可 以 得 出 以 下 几 点 : 
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对 于 类 EC2 + RightScale 系统 ，PhoenixCloud 系统 中 所 允许 的 最 低 系 统 容量 是 由 尖峰 资 

源 消耗 决定 的 ， 六 个 异 构 负载 的 尖峰 资源 消耗 降低 了 18% ， 每 个 服务 提供 商 运行 并 行 批 处 
理 作业 的 吞吐 量 接近 于 使 用 类 EC2 +RightScale 系统 ， 并 且 每 个 服务 提供 商 运行 并 行 批 处 理 


作业 负载 都 节省 了 资源 消耗 ， 对 于 每 个 终端 用 户 ， 平 均 周转 时 间 有 少量 增加 ， 分 别 为 29%， 
24% 和 15%。 


得 出 这 一 实验 结果 有 三 方面 原因 : (1) .在 PhoenixCloud 系统 中 ， 因 为 并 行 批 处 理 作业 
可 以 排队 ， 在 资源 上 限 以 外 的 资源 将 会 被 用 于 满足 需要 立即 做 出 响应 的 Web 服务 的 资源 请 
K, BEX EC2 系统 中 ， 由 于 充分 利用 了 统计 复 用 技术 ， 每 个 批 处 理 作业 所 需 的 资源 将 会 
被 立即 供应 。 因 此 ， 使 用 PhoenixCloud 系统 ， 资 源 提供 商 可 以 比 使 用 类 EC2 + RightScale 
系统 减少 尖峰 资源 消耗 。(2) .在 PhoenixCloud 中 ， 以 非 独占 式 的 模式 运行 异 构 负 载 的 每 组 
两 个 服务 提供 商 共 享 使 用 上 下 限 之 间 的 资源 ,通过 统计 复 用 技术 , 不 仅 可 以 防止 他 们 资源 浪 
绩 ， 同 时 也 降低 了 尖峰 资源 消耗 。(3) .对 于 资源 下 界 内 的 资源 ， 只 有 两 个 协同 的 服务 提供 
商 共 享 使 用 ， 而 不 需要 动态 的 要 求 或 释放 ， 因 此 ， 我 们 的 方法 降低 了 管理 开销 。 


B.3 不 同 负载 规模 的 实验 


附录 B 表 5. 
负载 


不 同 负 载 规模 下 的 资源 提供 商 指标 


本 节 讨 论 不 同 负载 规模 (PRC 
节 讨 论 不 同 负 载 规模 (PRCA， SKE, | HOE 


PRC) XT AIREA AA DEDE A 
最 终 用 户 的 影响 。 负 载 组 合 是 ((iPSC， 


Clark), (SDSC, WorldCup)). Phoenix 
Cloud 系统 的 基线 配置 为 [R0.5\E400\ 


((PRCA; PRCB), (PRCA; PRCB)) 


资源 损耗 


损耗 总 量 


((128,128),(144,128)) 


66.396 


15.196 


((128,64),(144,68)) 


62.596 


22.196 


U1.2\V0.1\L60]. 我 们 假定 系统 容量 是 
无 限 的 ， 并 且 资 源 预订 阅 值 RBT 和 
使 用 率 参 考 值 URR 分 别 设置 为 1。 在 下 面 的 实验 , 并 行 的 批 处 理 作业 负载 的 规模 与 附录 B.2 


节 相 同 ， 而 我 们 用 不 同 的 常量 扩展 了 Web 服务 负载 的 追踪 。 


((128,256),(144,256)) 


62.5% 11.9% 


附录 B 表 6. ”NASA 和 Clark 在 不 同 负 和 载 规 模 附录 B 表 7. ”SDSC 和 World 在 不 同 负 载 规 
下 的 并 行 批 处 理 作业 模 下 的 并 行 批 处 理 作业 
J TR TA gpp a TR OTH api 
(PRCA; RCB) 作业 数 ”周转 时 间 (PRCA; RCB) ”作业 数 ”周转 时 间 
(128,64) 2603 780 36808 (144,64) 2656 2624 33716 
(128,128) 2603 979 36518 (144,128) ^ 2656 2559 35093 
(128,256) 2603 2686 36287 (144,256) | 2652 2443 39600 


d 5. X 6. € 7 显示 了 实验 结果 。 我 们 可 以 看 到 : 第 一 ， 对 于 资源 提供 商 ， 相 比 类 
EC2+RightScale 系统 ， 人 尖峰 资源 消耗 降低 了 60% 左 右 ， 此 结果 与 PRC» 和 PRC, 的 比值 无 
Xs 当 PRCs Fil PRCA 的 比值 增加 时 ， 资 源 消耗 总 量 降 低 。 其 次 ， 当 Web 服务 负载 有 很 大 的 
资源 需求 时 , PRCs 和 PRCA 比值 的 增加 , 将 导致 并 行 批 处 理 作 业 很 大 的 延迟 , 这 是 因为 Web 
服务 的 优先 级 高 于 并 行 批 处 理 作 业 。 如 图 1 和 图 2 Bras, 与 WorldCup 相 比 ，ClarkNet 变化 
比较 平缓 ， 但 后 者 有 更 持久 的 资源 需求 ， 因 此 当 PRCs 与 PRC, 的 比值 增加 时 ，ClarkNet fà 
载 导 致 并 行 批 处 理 作 业 平 均 周转 时 间 拉 长 。 


B.4 不 同 参数 的 影响 
本 节 探 讨 PhoenixCloud 系统 中 不 同 的 效果 参数 。 


于 篇 幅 的 限制 ， 我 们 无 法 一 一 呈现 
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看 向 数据 中 心 异 构 负载 的 低 成 本 协同 资源 供应 方法 和 系统 


数据 的 所 有 参数 组 合 情 况 ， 我 们 采用 将 一 个 或 两 个 参数 变化 而 其 他 参数 保持 相同 基线 配 
置 [R0.5/E400/U1.2/V0.1L60]。 我 们 假定 资源 容量 是 无 限 的 ， 分 别 设置 资源 预订 阔 值 RBT 和 
使 用 率 参 考 值 URR 为 1。 


B.4.1 资源 上 界 的 影响 


图 4 和 图 5 显示 了 对 于 资源 提供 资源 消耗 〈iPSC) 资源 消耗 (SDSC) 
商 和 服务 提供 商 ， 资源 上 界 调整 带 来 ”-* AER GPSCO = 吞吐 率 (SDSC) 
的 影响 。 5 3.0 


A 


我 们 可 以 看 到 ， 当 资源 上 界 与 
PRCzg 和 PRC, 的 总 和 的 比值 小 于 2 
时 ， 人 尖峰 资源 消耗 增加 。 当 资源 上 界 


数 x 小 时 (10) 
CD 


M 
M 
a 
Yew ax (10°) 


与 PRCe 和 PRCaA 的 总 和 的 比值 接近 1 — ug 

时 ，PhoenixCloud Zt Eg F4 

总 资源 消耗 和 更 低 的 吞吐 量 。 在 实验 2 BE BIS mS S 

中 ， 我 们 建议 设置 资源 上 界 与 PRCB 0 "E200 E300 E400 E500 £600 E700 2.0 
和 PRCA 的 总 和 的 比值 为 1.5。 资源 上 办 


附录 B 图 4， ”不同 资源 上 界 的 资源 提供 商 指 标 


资源 消耗 (iPSC) 资源 消耗 (SDSC) 
- Fit (PSC) = AHR (SDSC) 


5 3.0 
4 人 人 
Te © 
= d 
23 i N- = 

x 2.5 XR 
E = 
^ g 
Fa 

lars poe 5 E e A 20 
E200 E300 E400 E500 E600 E700 
资源 上 界 
附录 B 图 5.， 不同 资源 上 界 的 服务 提供 商 指 标 
B.4.2 资源 下 界 的 影响 


DS 


6 和 图 7 显示 了 资源 下 界 调整 对 资源 提供 商 和 服务 提供 商 的 影响 。 我 们 可 以 看 到 , VE 
源 提供 商 的 总 资源 消耗 与 资源 下 界 成 正比 ， 而 资源 下 界 对 尖峰 资源 消耗 的 影响 不 大 (R0.4 
除外 ); 对 于 服务 提供 商 ， 资 源 消耗 与 资源 下 界 成 正比 ， 在 同一 时 间 ， 较 低 的 资源 下 界 会 导 
致 一 些 负载 吞吐 量 下 降 〈 对 于 iPSC 负载 ， 小 于 0.4)。 在 实验 中 ， 我 们 建议 将 R 的 值 设置 为 
0.5。 
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源 消 耗 > 峰值 资源 损耗 


14 800 
12 700 
600 
10 
500. 
o8 : 
2 400 iP 
ae 300 
x 
& 4 200 
In 
HF 2 100 
0'RO.7 RO.2 RO.3 R04 RO.5 RO.6 RO.7 ROS ^ 
资源 下 界 大 小 的 比率 
附录 B 图 6。 ”不同 资源 下 界 的 资源 提供 商 指 标 
CO 资源 消耗 〈iPSC) 资源 消耗 (SDSC) 
t AIX (iPSC) a ÆI% (SDSC) 
5 3.0 
d a 
H [e] 
至 | ee eee ge gL a 
Oo 
E 2.5 = 
ie & 
F] 
OMEN NEN NEM NEM D 
RO.1 RO2 RO3 RO4 RO.5 RO6 RO7 ROB 
000000000 
附录 B 图 7. 不 同 资源 下 界 的 服务 提供 商 指 标 
B.4.3 请 求 资源 与 释放 资源 比率 阔 值 的 影响 
图 8 和 图 9 显示 了 请 求 /释放 资源 全 部 资源 消耗 号 ”峰值 资源 消耗 
的 阔 值 比率 对 于 资源 提供 商 和 服务 供 10 
应 者 的 影响 。 我 们 可 以 看 到 : 请 求 和 释 : 
JACO Ua AY EE K Be [ES] PEST FE A Sec RU 8 
服务 提供 商 的 影响 不 大 。 在 同一 时 间 ， g6 
尖峰 资源 消耗 随 着 释放 资源 的 闵 值 比 po 
例 的 增加 而 增长 。 在 实验 中 , 我 们 建议 n 
A ACH U 和 M 为 1.2 和 0.1。 T “| is zt ases “4 een eee 
租赁 资源 的 时 间 单 元 的 影响 : 我 们 TE LI ULT UL ul2 u12 u2.0 u2.0 u2.0 9 


把 租赁 时 间 单 元 从 15 分 钟 改 到 60 分 v0.1 v0.5 v0.8 v0.1 v0.5 v0.8 v0.1 v0.5 v0.8 
h, KI 10 FH L15. L30 f! L60 分 别 请 求 资源 与 释放 资源 之 比 


意 谓 着 租赁 时 间 单 元 为 15、30 和 60 分 附录 B 图 8.， 不 同 闵 值 比例 的 资源 提供 商 指标 
钟 。 由 我 们 的 实验 可 以 得 出 结论 : TH 
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N 
a 


作业 数 (103) 


下 向 数据 中 心 异 构 负 载 的 低 成 本 协同 资源 供应 方法 和 系统 
赁 资源 的 时 间 单 元 对 资源 供应 者 影响 不 大 。 
资源 消耗 (iPSC) 资源 消耗 (SDSC) 
A- WdHEAXSNPSC) — -m- 硅 吐 率 (SDSC) 
4 
$3 
22 
x 
H1 
2 
0 ut dtu 4 uZ u $2 u20u20 U 0 2.0 
v0.1 v0.5 v0.8 v0.1 v0.5 v0.8 v0.1v0.5 v0.8 
请 求 资源 与 释放 资源 之 比 
附录 B 图 9. ”比例 闵 值 服务 提供 商 指 标 
全 部 资源 消耗 
—@— 峰值 资源 消耗 
7 
和 ~ 6 
o — 
= sD 
< 31r 
ES £ 
JE 2 
+P. 1 
ieee m 0 
L15 L30 L60 
租用 时 间 单 元 
附录 B 图 10. 在 不 同时 间 单 元 释放 资源 ， 资 源 提供 商 指 标 


B.5 合成 MapReduce 负载 


附录 B 表 8. Facebook 和 我 们 的 负载 中 ， 按 照 map 人 和 有 


F 务 数量 来 算 ， 作 业 大 小 的 影响 


分 组 在 facebook 在 facebook 在 负载 中 在 负载 中 
的 Map 数 的 作业 的 Map 数 的 作业 数 
1 1 3996 1 201 
2 2 1696 2 81 
3 3220 1496 10 65 
4 21-60 996 50 32 
5 617150 696 100 27 
6 1514300 696 200 28 
7 301~500 4% 400 19 
8 >500 7% 1300 24 
根据 对 Facebook2009 年 10 月 为 期 一 周 的 日 志 记 录 ! 的 分 析 ， 我 们 通过 选择 不 同类 型 和 大 


小 的 MapReduce 作 业 合 成 了 MapReduce 负 载 。 合 成 的 MapReduce 的 负载 包括 500 个 作业 。 首 先 ， 
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民 据 对 Facebook 日 志 的 分 析 ， 合 成 的 负载 的 任务 数量 从 1 到 1300 不 等 。 表 8 显示 了 Facebook 的 
日 志和 我 们 的 合成 负载 。 第 二 步 ， 如 表 9 所 示 ， 我 们 合成 的 MapReduce 负 载 的 作业 类 型 是 从 
不 同类 别 Hadoop 应 用 选择 的 ， 例 如 ， 分 析 和 统计 类 别 的 词 频 计 算 〈Wordcount) ， 排 序 算 法 
类 别 的 排序 和 TeraSort， 计 算 类 应 用 BBP 等 等 。 第 三 步 ， 我 们 通过 产生 从 1 到 500 的 随机 数 序 
列 ， 生 成 作业 提交 顺序 。 第 四 ， 根 据 对 Facebook 日 志 的 分 析 ， 我 们 设 定 作 业 提 交 后 的 到 达 时 
间 间 隔 遵从 均值 为 140 秒 的 指数 分 布 。 


附录 B 表 9. ”在 合成 MapReduce 负 载 中 ， 作 业 类 型 和 大 小 的 影响 
作业 类 型 每 类 的 作业 数 作业 运行 次 数 


Terasort* 


WordCount 


“Hadoop 的 基准 测试 程序 
* 词 频 度 计算 
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